¿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.

Advertisements

Presentando discos virtuales como iSCSI

Cada vez son más las organizaciones que optan por la virtualización y los escenarios de alta disponibilidad, por lo que se está transformando en un panorama habitual dentro de muchas empresas.

A veces necesitamos levantar un cluster sobre un cluster o generar algún ambiente de laboratorio, siendo necesario presentar unidades de disco por iSCSI.

El problema se presenta cuando las empresas no tienen permitido presentar unidades de iSCSI directamente desde el storage hacia maquinas virtuales por políticas de administración, seguridad y respaldo.

Con versiones anteriores a Windows Server 2012 R2 era posible presentar unidades como iSCSI utilizando herramientas que se descargan e instalan, o bien, usando Windows Server Storage.

Hoy con Windows Server 2012 R2 es posible presentar discos duros virtuales como unidades iSCSI hacia otra máquina, a través de la instalación y configuración de un rol.

A continuación mostraremos como hacerlo.

Instalar el rol iSCSI Targer Server

1m

Una vez instalado el rol, debemos ir a las máquinas donde se presentará esta unidad por iSCSI y abrir iSCSI Initiator.

Al abrir la herramienta de configuración por primera vez, se presentará este aviso.

2m

Debemos hacer click en Yes para que la configuración funcione. De otra forma, el cliente no podrá ver la unidad del servidor.

Cuando el servicio este habilitado, se mostrará la ventana principal de la herramienta:

3m

Por el momento dejaremos stand by la herramienta, para seguir con la configuración del servidor.

Anteriormente explicamos que las unidades que se presentan como iSCSI son archivos de disco duro virtual. Por lo que tenemos que tener especial cuidado con el disco físico, donde estarán estas unidades virtuales y de la carga de trabajo que tendrán.

Para crear una unidad, desde la consola de Server Manager, debemos navegar hasta la administración del rol e invocar al asistente:

4m

Luego debemos seleccionar el servidor y el volumen que contendrá a la unidad virtual que se creará:

5m

Al concluir la selección debemos hacer click en next.

En este slide nos pedirá ingresar los datos de nombre y descripción de la nueva unidad que se está creando:

6m

Debemos definir el tamaño y tipo de unidad virtual a crear:

7m

En mi laboratorio, tengo dos unidades creadas. Si no tienen unidades creadas, el listado les aparecerá vacío y solo estará disponible la opción de crear un target nuevo:

8m.jpg

Si el listado está vacío deben completar la información del nuevo target.

9m.jpg

Si nuestro nombre de target tiene caracteres no permitido, la herramienta se encarga de corregirlos.

10m

Este paso es muy importante, ya que definirá quién (máquina) podrá acceder a este recurso. En primera instancia, el listado aparecerá vacío. Se deberán agregar los accesos con la herramienta:

11m

En Add se abrirá una ventana donde debemos seleccionar quien tendrá acceso. Se puede escoger a través del nombre de la máquina o seleccionar desde el listado, si es que nuestro servidor ya conocía la máquina cliente:

12m

Una vez ya seleccionada la máquina, aparecerá la dirección en el listado (se puede agregar más de uno):

13mjpg

En este ejemplo, la autenticación no será necesaria.

14m.png

 

Debemos confirmar la nueva unidad a crear:

15m

La creación de la unidad dependerá del tamaño que se haya definido y del tipo de unidad que se escogió:

16m

17m

¡La unidad ya está creada! ahora debemos conectar a través de la herramienta iSCSI Initiator en la máquina cliente.

La herramienta ya es conocida por lo que solo se debe escribir el nombre del servidor y hacer click en Quick Connect:

18m

¡Listo! La unidad ya está disponible en la herramienta Disk Management para ser inicializada, formateada y dar un buen uso:

19

Si esta configuración se usará en un ambiente productivo, se recomienda realizar pruebas de rendimiento para conocer, valga la redundancia, el rendimiento de la unidad.

Maximiliano Marín, Consultor de Infraestructura, Blue Solutions.

¿Cómo se debe configurar el SPN para la migración de File Server?

No hay migración de servicios que no esté acompañada de dolores de cabeza. Especialmente si son servicios críticos para las organizaciones, como es el caso de los servidores de archivos.

Nunca hay que creer cuando comentan que la migración de un File Server es solo mover los archivos de un lugar a otro usando Robocopy y luego hacer el cambio en el servidor DNS para que siga conservando el mismo nombre que el servidor de origen y el cambio sea transparente a los usuarios.

Antes de explicar el cambio de SPN, me gustaría que se entendiera el concepto de SPN en su definición más fundamental.
SPN viene de la sigla de Service Principal Name.
Éstos deben estar asociados a un objeto de Active Directory (cuenta de usuario, grupo o computador) en el cual el servicio se ejecuta. Su función principal es soportar la autenticación mutua entre un cliente y un servicio.

Entonces, la configuración de un SPN consiste en la asociación de un servicio a un objeto de AD. Un objeto de AD puede tener varios SPN asociados, pero un SPN solo puede estar asociado a un objeto de AD. En el caso de que se duplique un SPN, vendrán los problemas.

Cuando se realiza una migración de File Server y posteriormente se hace el cambio en el DNS para que el antiguo servidor apunte al nuevo y se intenta acceder a la ruta, el visor de eventos mostrará un error así:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SRV-NUEVO$. The target name used was cifs/SRV-VIEJO. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMINIO.CL) is different from the client domain (DOMINIO.CL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server. 

Como el SPN no estaba configurado de forma correcta, no es posible hacer ni mantener la autenticación, por lo tanto, da error.

Para configurar el SPN, se debe hacer con una cuenta con privilegios sobre el dominio.

Eliminando un SPN
Antes de asignar un SPN a un objeto, hay que eliminarlo  del objeto al cual estaba asignado. Se debe seguir la sintaxis:
setspn -D servicio/host ObjetoAD Por ejemplo:

setspn -D host/srv-viejo.midominio.cl srv-viejo

setspn -D host/srv-viejo srv-viejo
setspn -D cifs/srv-viejo.midominio.cl srv-viejo
setspn -D cifs/srv-viejo srv-viejo

De esta forma se elimina los SPN asociados al file server del objeto srv-viejo.

Asociar un SPN
Una vez desasociados los SPN al antiguo objeto, se debe asociar al nuevo objeto. La sintaxis es:
setspn -S servicio/host ObjetoAD Por ejemplo:

setspn -S host/srv-viejo.midominio.cl srv-nuevo
setspn -S host/srv-viejo srv-nuevo
setspn -S cifs/srv-viejo.midominio.cl srv-nuevo
setspn -S cifs/srv-viejo srv-nuevo

De esta forma, el servicio podrá autenticar y mantener la autenticación. El recurso compartido es accesible desde los clientes. Hay que tener un especial cuidado con los clientes con Windows XP. Por que aparte de configurar los SPN correspondientes, también hay que hacer un cambio en el editor del registro de Windows. Seguir la documentación de este link: https://support.microsoft.com/en-us/kb/281308

Más información sobre la herramienta setspn se puede encontrar en: https://technet.microsoft.com/en-us/library/cc961723.aspx

Podemos concluir que las migraciones de File Server, no son tan sencilla ni con pocos pasos como afirman algunos, hay que realizarlas de manera cuidadosa para no incurrir en errores.

Maximiliano Marín, Consultor de Infraestructura, Blue Solutions.