Configuración ambiente híbrido Exchange 2013 con O365

Este artículo tiene como finalidad dar a entender cómo se realiza un ambiente híbrido entre la organización de Exchange Server 2013 on-premise con la plataforma de Exchange Online. Se entregarán detalles sobre los pre-requisitos necesarios para la implementación, y los pasos a seguir para una configuración exitosa.

Antes de comenzar con la implementación del ambiente híbrido, se deben cumplir ciertos requisitos, esto con el fin de mantener una plataforma dentro de las mejores prácticas.

  • Dominios verificados
  • Sincronización con el directorio
  • Certificado CA válida
  • Servicios de Exchange 2013 públicos
    • Autodiscover
    • EWS
  • Cuentas privilegios de administrador
    • Office 365
      • Global Administrator
    • On-premise
      • Enterprise Administrator
      • Domain Administrator
      • Schema Administrator
      • Organization Management

Sincronización con el directorio

Antes de comenzar, es necesario tener la plataforma de Office 365 sincronizada con el Active Directory on-premise, esta sincronización se logra a través de una herramienta llamada Azure AD Connect, la cual se obtiene desde el portal de office 365.

Dominios aceptados

Para poder coexistir la plataforma de Exchange on-premise con Exchange Online, es necesario verificar los dominios que se mantengan en la plataforma. Para lograr esto, desde la consola de administración de Exchange 2013, debemos dirigirnos al menú de organización y habilitar el federation trust.

11

Una vez habilitado, a través de PowerShell de Exchange debemos obtener el registro DNS para validar la autenticidad del dominio a través del script get-federatedDomainProof -DomainName <midominio.cl>.

Este script nos otorgará una visión del registro que necesitaremos ingresar en el DNS público para validar el dominio.

22

En el valor DnsRecord nos otorgará el nombre del dominio, el tipo de registro, el cual es un registro TXT, y el valor otorgado para el registro.

33

Una vez añadido el registro, podemos comenzar la configuración del ambiente híbrido.

Habilitar ambiente híbrido

Para poder habilitar el ambiente híbrido, una vez realizado los pasos anteriores, desde la consola de administración de Exchange 2013, en el menú de hybrid habilitaremos la configuración dando click en enable.

44

Solicitará iniciar sesión en Office 365 con credenciales de Administrador Global.

55

Una vez iniciada sesión, nos descargará el Hybrid Configuration Wizard (HCW), el cual debemos instalar en una máquina que se encuentre dentro de la red de los servidores, de esta forma detectará automáticamente los servidores óptimos a utilizar.

66

77

Luego de seleccionar el servidor de Client Access a utilizar, debemos dar click en next y nos solicitará credenciales con privilegios de administrador de la plataforma on-premise y cloud.

88

Es necesario que estas cuentan cumplan con los roles de administradores específicos, ya que serán verificadas para poder continuar con la configuración.

99

Una vez validadas las cuentas, se seleccionará el servidor que se utilizará para la seguridad de transporte de correos entre las plataformas, esto puede realizarse a través de un servidor de Client Access o de un servidor de Edge Transport.

10

111

Nota: En caso de utilizar un servidor de Client Access, la configuración es exactamente la misma.

Para finalizar con la configuración, se debe seleccionar el certificado de una CA válida, el cual será utilizado para crear una conexión segura entre ambas plataformas y el nombre con el cual los servicios EWS fueron publicados, por ejemplo mail.midominio.cl.

222

333

Una vez finalizado el HCW podremos acceder a la consola de administración de Exchange Online, a través de la misma consola de Exchange 2013.

444

Y desde el menú de organization podremos ver que se está compartiendo la información con Exchange Online.

555

Ernesto León, Consultor Infraestructura, Blue Solutions.

Ejecución manual de DirSync

Dependiendo de la versión de la solución de sincronización que está utilizando para replicar los datos del directorio desde el Active Directory local a Office 365 hay diferentes comandos que tendrá que utilizar.

Podemos ver una lista de las versiones DirSync en la wiki de TechNet, y para AAD Sync, los listados de versión son en MSDN.  A pesar de esto, ahora ha sido reemplazado con otro artículo que tiene información de la versión de sincronización y AAD AAD Conectar.

Los términos completos de sincronización y sincronización delta no son exclusivos de las herramientas de Microsoft aquí expuestas. Una sincronización completa hará exactamente eso, sincronizar todos los objetos sin tener en cuenta si ya está sincronizado. Esto tomará una cantidad significativa de tiempo en un gran residente. Una sincronización completa se producirá cuando la herramienta de sincronización de directorios se instala por primera vez, ya que esto es necesario para obtener todos los objetos que están en el ámbito de la sincronización en Azure Active Directory. Una vez que los objetos están allí, solo se encripta la información del objeto (por seguridad) y aquí es donde la sincronización delta entra en acción. Una sincronización delta sólo se replican los cambios desde la sincronización anterior por lo que es más rápido y más eficiente en general.

Azure AD Connect (Conectar AAD) Febrero el año 2016 Build (1.1.105.0) en adelante

En febrero el año 2016, build 1.1.105.0 de Azure AD Connect fue liberado, introdujo varias nuevas características. El planificador está ahora integrado en el motor de sincronización, esto significa que ya no es una herramienta DirectorySyncClientCmd separada.

Para iniciar una sincronización delta, abra Windows PowerShell y ejecutar:

Start-ADSyncSyncCycle -PolicyType Delta

Para iniciar una sincronización completa, abra Windows PowerShell y ejecutar:

Start-ADSyncSyncCycle -PolicyType Initial 

Pierre añadió un comentario que indica que si los comandos no son visibles, trate de cargar el módulo de PowerShell:

Import-Module “C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1”

Azure AD Connect (Conectar AAD) Diciembre el año 2015 Build (1.0.9131.0) y es mayor

De junio del año 2015 vio el lanzamiento de Azure AD Conectar el cual es el sucesor de Azure AD Sync. A partir del momento de la escritura, la última versión del AAD Connect es 1.0.8667.0. Eso va a cambiar con el tiempo, así que por favor echa un vistazo a la información de versión sobre AAD AAD Sync y Conectar

Al igual que con la herramienta de sincronización de AAD se encuentra en:

C:\Program Files\Microsoft Azure AD Sync\Bin

Para realizar una actualización manual, utilice la herramienta DirectorySyncClientCmd.exe. El Delta y parámetros Initial especifican la tarea correspondiente.

1

La pantalla de abajo fue tomada de acumulación 1.0.9131.0 de Azure AD Conectar.

2

Azure Active Directory Sync Services (AAD Sync)

Para septiembre de 2014 se publicó la herramienta Microsoft Azure AD Sync, esto cambió cómo se emiten solicitudes de sincronización manual.

Para realizar una actualización manual, ahora utilizamos la herramienta DirectorySyncClientCmd.exe. El Delta y parámetros iniciales se añaden al comando para especificar la tarea correspondiente.

Esta herramienta se encuentra en:

C:\Program Files\Microsoft Azure AD Sync\Bin

Windows Azure Active Directory Sincronización – Junio 2014 Build 6862 Adelante

Con construir 6862 el módulo de PowerShell se ha movido. La ubicación de este módulo es ahora:

C:\program Files\Windows Azure Active Directory Sync\DirSync\ImportModules.ps1

Que nos permita ejecutar el cmdlet Start-OnlineCoexistenceSync que puede:

Abra Windows PowerShell y Import-Module DirSync

Abrir Windows PowerShell y ejecute el archivo de Import-Modules.ps1

Windows Azure Active Directory Sincronización – Abril 2014 Construye viejo que 6765

En la anterior obra de sincronización de directorios, usaríamos los DirSyncConfigShell.psc1 que se encuentran en:

C:\Program Files\Windows Azure Directory Sync

o

C:\Program Files\Microsoft Online Directory Sync

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

Ventanas de mantenimiento con SCCM

Es tarea del departamento de TI y soporte hacer mantenimiento en las estaciones de trabajo. El mantenimiento implica la ejecución de las revisiones de los antivirus, limpieza de los equipos, distribución de configuración, distribución de aplicaciones, y la más temida, distribución de actualizaciones.

Es muy habitual que se implemente una mala política de distribución de actualizaciones a nivel corporativo. Esta política es sencillamente no distribuir actualizaciones.

Los motivos para no distribuir actualizaciones he visto que principalmente son 3:

  • Porque no son necesarias
  • Porque son una molestia para los administradores y para los usuarios
  • Porque no cuentan con una herramienta que permita optimizar el proceso

No entraremos en discusión sobre las buenas prácticas al respecto, pero sí me quiero centrar en el punto 2.

El punto 2 está condicionado a que no se dan las ventanas de trabajo para que se realice esta importante tarea y es ahí donde quiero llegar.

Las ventanas de mantenimiento son espacios de tiempo en los que los usuarios no se encuentran trabajando. Es un espacio donde el horario hábil ya acabó y se pueden ejecutar las tareas automatizadas, como la de distribución de actualizaciones.

Con System Center Configuration Manager se puede configurar las ventanas de mantenimiento a nivel de colección y configurar la distribución de paquetes para que se realice la instalación dentro de esa ventana.

Generando una ventana de mantenimiento por colección, puede darse el caso que a una máquina tenga asignada dos o más ventanas de mantenimiento.

Si las ventanas de mantenimiento no tienen tiempo en común, serán tratadas como ventanas de mantenimiento aparte.

Si las ventanas de mantenimiento tienen tiempo en común, se considerará la extensión total de las ventanas. Por ejemplo: Si dos ventanas de mantenimiento de una hora de extensión cada una, sobre un equipo, tienen un tiempo en compartido de 30 minutos, la ventana será de 90 minutos.

La configuración de una ventana de mantenimiento para colección, se tiene que hacer en las propiedades:

11

Vista de las ventanas de mantenimiento creadas

12

Configuración de la agenda de la ventana de mantenimiento

Al momento de la distribución de una aplicación se puede configurar cual es la acción que se puede tomar una vez que la fecha límite de instalación ha sido alcanzada:

13

Configurando ventanas de mantenimiento se genera un ambiente saludable para que los usuarios puedan realizar sus actividades de forma cotidiana y TI pueda desarrollar las suyas correspondientes en el mantenimiento y soporte de las estaciones de trabajo de los clientes internos.

14

Maximiliano Marín, Consultor Infraestructura, Blue Solutions.

 

Proteger todas las OU a la vez contra eliminación Accidental

Cada administrador de Active Directory debe saber que existe una configuración por defecto desde que apareció RSAT con Windows Vista y que se activa por defecto al momento de crear una nueva Unidad Organizativa. Esta funcionalidad reside en proteger la OU que vayamos a crear contra eliminación accidental, provocando que el técnico que quiera eliminar la OU deba primero desbloquear la limitación para poder eliminar la OU.

El siguiente paso a paso a explicar es un poco delicado, ya que si no se está seguro o si no se tienen los conocimientos suficientes de Active Directory, más algo de línea de comandos, será un poco extraño y posiblemente difícil de entender.

El procedimiento que vamos a seguir es un comando desde una cmd.exe que bloqueará al usuario (todos o everyone) según idioma contra eliminación de objetos he hijos, para así en caso de que un técnico por error vaya a eliminar una OU, ésta estará protegida contra eliminación.

Lo primero de todo, es diferenciar entre el lenguaje del sistema operativo donde vamos a realizar el comando, ya que en el caso que esté en inglés al usuario que le vamos a quitar los privilegios es “everyone” y si está en español es “todos”.

Crear una OU de pruebas sin marcar el pincho “Proteger objeto contra eliminación accidental”.

Desde una línea de comandos y con las herramientas de Active Directory instaladas, ejecutar el siguiente comando:

for /F “tokens=*” %i in (‘dsquery ou “ou=pruebas,dc=dominio,dc=com” -limit 0’) do dsacls %i /D “todos”:”SDDT;;”

Cuando esté realizado, nos vamos a las propiedades de la OU en el ADUC y comprobamos que el pincho “Proteger objeto contra eliminación accidental” vuelve a estar marcado como en la siguiente imagen:

3

El comando que vamos a usar para modificar los permisos de todas las OU’s del directorio activo para proteger contra eliminación accidental es el siguiente:

For /F “tokens=*” %i in (‘dsquery ou –limit 0’) do dsacls %i /D “everyone”:”SDDT;;”

Con este comando realizamos una búsqueda de todas las OU’s de AD (‘dsquery ou –limit 0’) y por cada resultado se le hace un dsacls para que el usuario everyone no pueda eliminar objetos (SD) y tampoco eliminar los hijos de los objetos (DT).

Recordar cambiar el nombre “everyone” por “todos” si el idioma de sistema operativo está en castellano.

Se mostrará por pantalla todos los permisos de todas las OU’s (este proceso es normal, no se asuste). NO CIERRE LA VENTANA.

El proceso tardará más en función de la organización de AD (Si es muy grande puede tardar alguna hora).

Dentro de las buenas prácticas de Microsoft, todas las OU’s del dominio deben estar con esta configuración, para validar la aplicación de este cambio se recomienda ejecutar un BPA (Best Practice Analyzer) para el rol de AD DS.

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.