Content Index aparece como UNKNOWN en Exchange 2013

Uno de los problemas de indexación normalmente en la plataforma de Exchange, es el alto consumo de RAM en el servicio de Noderunner.exe, ya que la distribución de las bases de datos entre los servidores es esencial en una plataforma como esta. Para esto es necesario remediar un problema con la indexación de las bases de datos, las cuales no permiten la activación de la copia pasiva en ninguna de las bases de datos disponibles.

Las tareas a ejecutar para la remediación son las siguientes:

  • Realizar la reparación del content index state mediante las siguientes actividades
    • Eliminación de CI y reinicio de servicios
    • Reseteo de CI mediante el script de reparación de Exchange
    • Regeneración del módulo Microsft search

Solución

En el path: E:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Runtime\1.0

Buscamos el memoryLimitMegabytes en el archivo noderunner.config. Está establecido en 250.

————-

  <nodeRunnerSettings memoryLimitMegabytes=”250″/>

————- 

Luego lo cambiamos a 0 y reiniciamos el servicio Search Host Controller Service

El reinicio del Search Host Controller Service comenzará a realizar la reconstrucción de todos los índices por base de dato, por ende el tiempo en demorar la construcción depende mucho del tamaño por bases de datos (un par de horas).

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

Advertisements

Arquitectura Ideal de Exchange 2013 (PA)

Simplicidad

Las fallas ocurren. No hay tecnología que pueda cambiar eso. Discos, servidores, racks, redes, generadores, sistemas operáticos, aplicaciones (como Exchange), drivers, y otros servicios, simplemente no existe un servicio entregado por IT que no esté sujeto a fallos.

Una manera de mitigar las fallas es con una infraestructura redundante. Donde una entidad que falla, siempre tendrá una o más entidades para utilizar en su lugar. Esto se puede observar en los Web Server Array, disk array, y similares. Pero la redundancia puede ser costosa, por ejemplo, el costo y la complejidad del sistema de almacenamiento basado en SAN que estaba en el corazón de Exchange hasta la versión 2007, condujeron al equipo de Exchange en aumentar la inversión en almacenamiento para su arquitectura. Nos dimos cuenta de que cada sistema de SAN en última instancia, falla, y que la implementación de un sistema altamente redundante utilizando la tecnología SAN sería un costo muy alto. En respuesta a esto, Exchange a evolucionado de una exigencia costosa de alto rendimiento en almacenamiento SAN y periféricos relacionados, para ahora ser capaz de correr en servidores más baratos con los productos básicos SAS/SATA. Esta arquitectura permite a Exchange ser resistente a fallos relacionados con el almacenamiento permitiendo almacenar buzones de gran tamaño a un costo razonable. Con la construcción de la arquitectura de replicación y optimización de Exchange en almacenamiento, los fallos en temas de almacenamiento son prescindibles. Esta arquitectura no se detiene en la capa de almacenamiento, NIC redundantes, fuentes de poder, etc. Si se trata de un disco, controlador o placa base que falla, el resultado final debe ser el mismo, otra copia de base de datos se activa y se hace cargo. Cuanto más complejo sea el hardware o software de la arquitectura, los errores de hardware ya no se vuelven una prioridad. Ejemplos de redundancia complejos son pares activos/pasivos de red, puntos de agregación de la red con configuraciones complejas de enrutamiento, la colaboración de red, RAID, múltiples vías de fibra, etc. La eliminación de redundancia compleja no parece algo creíble, pero puede lograrse a través de una redundancia basada en Software. La Arquitectura preferida (PA) elimina la complejidad y redundancia cuando sea necesario para impulsar la arquitectura a un modelo de recuperación predecible: cuando se produce un fallo, se activa otra copia de la base de datos afectada.El PA se divide en cuatro áreas de interés:

  • Diseño de espacios de nombres
  • Diseño de datacenter
  • Diseño del servidor
  • Diseño del DAG

Namespace

Desde una perspectiva de espacio de nombres las opciones son, o bien implementar un espacio de nombres con destino preferido (que tiene una preferencia por los usuarios para operar fuera de un centro de datos específico) o un espacio de nombres no unida (que tienen los usuarios se conectan a cualquier centro de datos sin preferencia). El método recomendado es utilizar el modelo no unido, el despliegue de un único espacio de nombres según el protocolo de cliente para el par de estaciones tolerantes del datacenter (donde se supone que cada datacenter  para representar su propio sitio de Active Directory). Por ejemplo:

  • Autodiscover.dominio.com
  • Para clientes http: mail.dominio.com
  • Para clientes IMAP: imap.dominio.com
  • Para clientes SMTP: smtp.dominio.com

Cada espacio de nombre debe estar balanceado entre todos los datacenter en una configuración que no aprovecha la afinidad de sesión, lo que resulta en un cincuenta por ciento del tráfico se distribuye entre los datacenter. El tráfico se distribuye por igual entre los datacenter via DN round-robin, geo-DNS, o soluciones similares. Aunque desde nuestro punto de vista, la solución más simple es la menos complejo y más fácil de manejar, por lo que nuestra recomendación es aprovechar el DNS round-robin. En el caso de que usted tiene sitios múltiples de datacenter flexibles en su entorno, tendrá que decidir si quiere tener un único espacio de nombres en todo el mundo, o si desea controlar el tráfico a cada datacenter específico mediante el uso de espacios de nombres regionales. En última instancia su decisión depende de la topología de red y el costo asociado con el uso de un modelo no unido; por ejemplo, si usted tiene un datacenter ubicados en América del Sur y Europa, el enlace de red entre estas regiones podría no sólo ser costoso, si no también podría tener una alta latencia, que puede presentar dolor de cabeza para el usuario y las cuestiones operativas. En ese caso, tiene sentido para implementar un modelo enlazado con un espacio de nombres separado para cada región.

Diseño de Servidores

En la PA, todos los servidores son multi-rol y físicos. Se prefiere hardware físico por dos razones:

  • Los servidores se escalan para utilizar el 80% de los recursos en el peor de los casos.
  • La virtualización añade una capa adicional de administración y recuperación que no añaden valor a Exchange.

Mediante el despliegue de servidores multi-rol, la arquitectura se simplifica ya que todos los servidores tienen el mismo hardware, proceso de instalación y las opciones de configuración. Consistencia a través de servidores también simplifica la administración. servidores multi-rol proporcionan un uso más eficiente de los recursos del servidor mediante la distribución del CAS y los recursos del Mailbox a través de un mayor número de servidores. CAS y DAG son más resistente a fallas, ya que hay más servidores disponibles para el equilibrio de carga del CAS y para el DAG.

1

Figura 1: Diseño de servidores

Diseño DAG

Para cada sitio será necesario tener como mínimo un DAG.

Configuración del DAG

Al igual que con el namespace design, cada DAG dentro del sitio del datacenter opera en un modelo no unido con copias activas distribuidas por igual entre todos los servidores en el DAG. Este modelo ofrece dos ventajas:

  • Se asegura de que cada servicio de la base de datos se encuentre valida (conectividad con cliente, replicación, transporte, etc).
  • distribuye la carga a través de tantos servidores como sea posible durante un escenario de error, lo que aumenta de forma incremental solamente la utilización de recursos a través de los miembros restantes dentro del DAG.

Cada datacenter es simétrico, con igual número de servidores miembro dentro de un DAG que reside en cada datacenter. Esto significa que cada DAG contiene un número par de servidores y utiliza un servidor testigo de arbitraje quórum.

El DAG es el bloque de construcción fundamental en Exchange 2013. Con respecto al tamaño de DAG, un DAG más grande proporciona más redundancia y recursos. Dentro de la PA, el objetivo es el despliegue de los DAG con alta capacidad.

DAG Network

Desde la introducción de la replicación continua en Exchange 2007, Exchange ha recomendado tener múltiples redes de replicación, para separar el tráfico del cliente de tráfico de replicación. La implementación de dos redes le permite aislar ciertos niveles de tráfico a lo largo de las diferentes vías de la red y asegurarse de que, en determinados eventos la interfaz de red no este saturada. Sin embargo, para la mayoría de los clientes, que tiene dos redes que funcionan de esta manera era sólo una separación lógica, ya que el mismo tejido de cobre fue utilizado por ambas redes en la arquitectura de red subyacente.

Witness Server (Servidor de Testigo)

La utilización de un servidor de testigo determina si la arquitectura puede proporcionar capacidades de activación automática por datacenter en caso de fallas, o si se requerirá activación manual para subir el servicio. Si su organización tiene una tercera ubicación con una infraestructura de red que está aislado de los fallos de red que afectan el sitio del centro de datos par resistente en el que se despliega el DAG, entonces la recomendación es implementar servidor testigo del DAG en ese tercer lugar. Esta configuración ofrece la DAG la capacidad de resistencia a fallas y activación de copia pasiva en otro datacenter.

2

Figura 2: DAG (Esquema de 3 datacenter)

El PA se aprovecha de los cambios realizados en Exchange 2013 para simplificar la implementación de Exchange, sin disminuir la disponibilidad o la elasticidad del despliegue. Y en algunos casos, en comparación con las generaciones anteriores, la PA aumenta la disponibilidad y capacidad de recuperación de su implementación.

Ernesto León, Consultor Infraestructura, Blue Solutions.

Backup mailbox PST Exchange 2010/2013

En muchas organizaciones suelen tener distintos tipos de respaldos dependiendo de la importancia del negocio en donde estos estén enfocados. Al mismo tiempo, existen distintos tipos de herramientas que nos sirven para respaldar, los cuales hasta el día de hoy son líderes en el mercado del Backup Veeam, Symantec Backup exec, Azure Backup Vault, System Center Data Protection Manager, entre otros. En este caso también podemos acceder a la misma herramienta para realizar nuestro respaldo que en este caso les explicaré cómo realizarlo desde Exchange mediante Powershell.

Básicamente, la única opción disponible para respaldar nuestros correos es de forma granular a una exportación a archivos PST. Esto se puede hacer a través de Outlook (siempre), PowerShell y, en algunos casos, también a través de Exchange Management Console / Panel de control.

Exportación de un solo mailbox a PST mediante PowerShell

Lo primero que debemos realizar es asignar permisos para importar y exportar a un usuario específico.

New-ManagementRoleAssignment -Role “Mailbox Import Export” -User “<usuario>”

Luego de este script podemos comenzar con el respaldo del mailbox que deseamos respaldar.

New-MailboxExportRequest -Mailbox <user> -FilePath \\<server FQDN>\<nombre carpeta compartida>\<nombre PST>.pst

Mailbox: Cuenta de usuario a respaldar.

FilePath: Ruta de carpeta compartida donde almacenaremos el PST.

Exportación de mailbox de toda la organización mediante PowerShell.

Al igual que en el procedimiento anterior, si no está aplicado, debemos asignar permisos para importar y exportar a un usuario específico.

New-ManagementRoleAssignment -Role “Mailbox Import Export” -User “<usuario>”

Forma 1

Declaramos la siguiente variable en donde seleccionamos a todos los mailbox

$AllMailboxes = Get-Mailbox

después ejecutamos el siguiente script

$AllMailboxes|%{$_|New-MailboxExportRequest -FilePath \\<server FQDN>\<nombre carpeta compartida>\$($_.Alias).pst}

FilePath: Ruta de carpeta compartida donde almacenaremos el PST.

$._Alias: Nombre con el que se guarda el PST (en este caso aplica  a los alias de los usuarios).

Forma 2

En el caso de ser un listado de usuarios específico, debemos generar un CSV con el parámetro Identity y Alias de cada usuario.

$csv = Import-Csv “C:\Migracion365\Data\Password\$Domain.csv”

Luego ejecutamos el siguiente script

foreach ($line in $csv) { New-MailboxExportRequest -Mailbox $Line.Identity -FilePath “\\<server FQDN>\<shared folder name>\$($Line.Alias).pst” }

 

Bueno, espero que les haya servido de ayuda, ya que esta opción es muy buena si no disponen de herramientas de respaldo en donde puedan ocupar la técnica de Backup 3,2,1.

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

 

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.

¿Cómo podemos resolver el error NDR en Exchange 2013?

En más de una ocasión  dentro de las organizaciones nos podemos encontrar con algún mensaje  NDR al enviar mails internos a nivel On-premise en coexistencia (migración) en Exchange 2013.

Sólo se puede presentar un NDR cuando se envía un correo electrónico desde Exchange y se encamina a través de Hub Transport de éste.

El error se presenta de esta forma:

Delivery has failed to these recipients or distribution lists: contacto@luisarancibia.cl

 Your message wasn’t delivered because of security

 policies. Microsoft Exchange will not try to

 redeliver this message for you. Please provide the following

 Diagnostic text to your system administrator.

Esto sucede cuando el sender que tenemos en los atributos ProhibitSendReceiveQuota y ProhibitSendQuota es 0 KB para el mailbox que tiene el problema.

Para poder dar solución a nuestro problema debemos correr el siguiente cmdlet para obtener detalles sobre qué usuarios tienen problemas obteniendo NDR.

[PS] C:\Get-Mailbox -id “UserID” | fl IssueWarningQuota,ProhibitSendReceiveQuota,ProhibitSendQuota

Para obtener un listado con todos los usuarios que tienen 0 KB para ProhibitSendReceiveQuota y ProhibitSendQuota  podemos ejecutar el siguiente cmdlet.

[PS] C:\Get-mailbox-ResultSize Unlimited | where {($_.ProhibitSendReceiveQuota -eq 0KB -or$_.ProhibitSendQuota-eq 0KB) -and $_.UseDatabaseQuotaDefaults -eq”true”}

Una vez revisados los ProhibitSendReceiveQuota y ProhibitSendQuota para los usuarios, aplicaremos el cambio de 0 KB a ilimitado. Debemos ejecutar los siguientes scripts.

[PS] C:\Set-Mailbox -Identity “UserID” -IssueWarningQuota “unlimited”

[PS] C:\Set-Mailbox -Identity “UserID” -ProhibitSendReceiveQuota “unlimited”

[PS] C:\Set-Mailbox -Identity “UserID” -ProhibitSendQuota “unlimited”

Luego de ejecutar estos cambios, debemos volver a realizar pruebas funcionales y verificar si el flujo de correo es el deseado.

Los NDR pueden ser personalizados, si la organización lo desea manteniendo una base de datos interna de identificación por error, así podremos reconocer con mayor facilidad los usuarios con error.

Luis Arancibia, Consultor Cloud, Blue Solutions.

¿Cómo montar un laboratorio de Exchange 2013 en menos de una hora?

La finalidad de este artículo es crear un laboratorio de exchange 2013 para realizar pruebas antes de implementarlas en su plataforma de Exchange 2013 y analizar cómo se comporta, cuáles son los impactos y cuáles son los beneficios.

Etapas:

  • Instalación de prerrequisitos.
  • Descargar e instalar office 2010 Filterpack.
  • Descargar e instalar Office 2010 FilterPack service pack 2.
  • Descargar e instalar Microsoft Unified Communications Managed.
  • Instalar Actualizaciones de Windows 2012 r2.
  • Instalar Exchange 2013.

1.- Instalar prerrequisitos

Antes de comenzar con la instalación de nuestro laboratorio de Exchange, tenemos que cumplir ciertos requisitos previos, como el unir nuestro servidor a un dominio, ingresar con cuenta de administrador Enterprise e instalar roles y servicios necesarios para la instalación.

Para la instalación de roles y servicios en nuestro servidor, es necesario abrir un PowerShell como administrador y ejecutar:

Add-WindowsFeature Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Lgcy-Mgmt-Console,Web-Metabase,Web-WMI,Web-Net-Ext,Web-Basic-Auth,Web-Digest-Auth,Web-Dyn-Compression,Web-Stat-Compression,Web-Windows-Auth,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-Http-Tracing,WAS-Process-Model,Web-Mgmt-Console,Desktop-Experience,NET-Framework-Core,RPC-over-HTTP-Proxy,Telnet-Client,Windows-Server-Backup,RSAT-Clustering,RSAT-NLB,RSAT-ADDS,GPMC,Failover-Clustering,RSAT-Clustering-CmdInterface –Restart

1

Posterior a la realización de la instalación de los requisitos previos, y reiniciado el servidor, debemos:

a) Descargar e instalar office 2010 Filterpack

Una vez se encuentren los roles y características de prerrequisito instaladas, debemos descargar office 2010 FilterPack desde http://www.microsoft.com/en-us/download/details.aspx?id=17062 e instalamos.

b) Descargar e instalar office 2010 Filterpack ServicePack 2

A continuación de la instalación del FilterPack, se debe instalar el ServicePack 2 http://www.microsoft.com/da-dk/download/details.aspx?id=39668 e instalamos.

c) Descargar e instalar Microsoft Unified Communications Managed

Una vez instalado el FilterPack ServicePack 2 instalados solo queda descargar http://www.microsoft.com/en-us/download/details.aspx?id=34992 e instalar.

2.-Instalar Actualizaciones de Windows 2012 r2

Antes de instalar Exchange se debe tener el servidor completamente actualizado, para eso iremos a panel de control y en Windows Update buscaremos e instalaremos todas las actualizaciones, para luego reiniciar.

2

3.- Instalar Exchange 2013

Una vez instaladas las actualizaciones y el servidor reiniciado procedemos a instalar Exchange.

3

Cuando inicie el asistente, se deben buscar e instalar las actualizaciones de exchange y dar click en next.

45

Una vez descargadas las actualizaciones, dar click en next para continuar con la instalación.

6

Click en next.

7

Aceptar el acuerdo de licenca y click en next.

8.jpg

Usar las configuraciones recomendadas para tener el mejor escenario al momento de realizar pruebas en nuestro laboratorio.

9.jpg

Seleccionamos los roles a instalar en el servidor de Exchange.

10.jpg

Seleccionar la ruta de instalación y click en Next.

11.jpg

Ya que esto es un ambiente controlado, no será necesaria la instalación de la protecion contra Malware.

12.jpg

Ahora el asistente comenzará a verificar los prerrequisitos, una vez finalice, debemos hacer click en install y comenzará la instalación de Exchange 2013.

13

Una vez finalizada la instalación, podremos acceder a la consola web de administración de Exchange, a través de https://NombreServidor/ecp y comenzar a realizar las pruebas correspondientes.

14

15.jpg

Ernesto León, Técnico de Soporte, Blue Solutions