Registro de las conexiones RPC a los servidores de Acceso Clientes (CAS) en Exchange 2010.

La semana pasada a través de twitter  me llegó un post sobre logs de Exchange 2010 muy utiles que recolectar (ver este Post),  y pensé, pues creo que tengo que tener todos los logs de Exchange bien guardados, no hay mas que ver los siguientes posts:

Pero me faltaba uno ……¡Aaaaarrrggggg! Me falta el registro de conexiones RPC a los servidores de acceso cliente (CAS). Pues nada, lo solucionamos.

Por defecto,  Exchange 2010 realiza registro (logging) de conexiones a través del servicio RPC Client Access.  Este log, en principio no nos aportará mucha información a no ser que hayamos detectamos problemas de conexión en clientes a sus buzones y queramos verificar las conexiones RPC. Por defecto estos ficheros se encuentran en la ruta %ExchangeInstallDir%LoggingRPC Client Access:

logginRPCClient0001

Como habreis intuido, tenemos que encontrar el fichero que gestiona la configuración de este logging, que se encuentra en:

logginRPCClient0002

Lo editamos y podemos configurar los siguientes parámetros:

logginRPCClient0003

  • Habilitar/Deshabilitar.
  • Ruta donde se guardarán dichos ficheros logs.
  • Tamaño de los ficheros, por defecto son de 10 MB.
  • Cambiar el periodo de retención de los mismos que por defecto son 30 dias.
  • Ocupación máxima del almacenamiento de la carpeta, por defecto 1 GB.
  • Precisión.

En principio, como he dicho, solo vamos a cambiar la ubicación de estos ficheros desde la unidad C a otra. Asi que, cambiamos de %ExchangeInstallDir%\Logging\RPC Client Access a I:\Logging\RPC Client Access\

No hay que olvidarse que tendremos que reiniciar el servicio Microsoft Exchange RPC Client Access

logginRPCClient0006

Y ya está:

logginRPCClient0007

Saludos,

Bibliografia.

How Exchange works.

Exchange 2010 Error: Copia de la Base de Datos tiene los archivos de catalogo de indices en estado de Error.

Llego el pasado lunes a la oficina y me comentan que no podemos activar las copias pasivas de las bases de datos de un Cluster DAG de Exchange 2010 porque aparece el siguiente mensaje de error:

IndexServer00002

Busco en el visor de eventos y dicho mensaje no está considerado como un Warning o un Error. Solo es un evento Informativo!!

Para obtener algo mas de información ejecuto el siguiente cmdlet tratando de ver el estado de la copia de las Bases de Datos de buzones en cada servidor miembro del DAG, Servidor A y Servidor B:

IndexServer00001

Efectivamente, como se puede ver en la salida del cmdlet o en el evento informativo del inicio, el problema está en que la fecha y hora (timestamp) de los archivos de catálogos de índices de contenido de las bases de datos son demasiado antiguos.

Echando un vistazo por Internet encuentro problemas similares que se resuelven ejecutando el script de powershell ResetSearchIndex.ps1 que lo que realiza es:

  • Parar el servicio Search Indexer.
  • Borrar todos los ficheros de catálogo.
  • Iniciar el servicio Search Indexer.

Así que, valorando un poco las cosas y sabiendo que puedo actuar sobre el Servidor A ya que en estos momentos no esta en producción, pues reinicio el servicio Microsoft Exchange Search Indexer para ver si genera nuevamente el catálogo de índices, y ……

Solucionado. Espero que os sea util.

Bibliografia:

Exchange server troubleshooting from the filed!

Exchange Technet.

ExchangeServerPro.

Liberado Update Rollup 1 para Exchange Server 2010 SP3

Ayer teníamos una revisión de nuestro entorno de correo, lo que Microsoft define como Exchange Risk Assessment Program (ExRAP), y me pregunta  el Ingeniero, ¿Qué versión teneis de Exchange?, le respondo, 2010 con SP3. Y, me dice, pues ayer salió el Update Rollup 1!!! … y me vuelvo a quedar con cara de #%#@&$

ex2010sp3ur10001

El UP1 corrige los siguientes errores detectados ya sea por los propios técnicos de Microsoft como reportados por clientes:

ex2010sp3ur10004

Os dejo toda la información que he podido recabar en los siguientes links:

Por cierto, hay que tener en cuenta esta peculiaridad a la hora de instalarlo sobre Exchange 2010 que funcionen sobre Windows Server 2012 con versión DBCS, o sea, Double-Byte Character Set o caracteres extendidos :

ex2010sp3ur10003

Buen fin de semana.

Test-ActiveSyncConnectivity – Cmdelts de Testeo 13/32.

Continuamos con los Posts sobre los cmdlets de testeo que tenemos en Exchange 2010 SP2 (aqui). Esta semana llevamos uno por dia. Hoy Test-ActiveSyncConnectivity, un clásico muy utilizado.

¿Que realiza?

Lleva a cabo una sincronización completa entre el dispositivo móvil y un buzón determinado para comprobar la funcionalidad del servicio de ActiveSync.

Test-ActiveSyncConnectivity


En esta prueba básica, al no especificar ningún buzón selecciona el que tenemos creado de Test en nuestra organización (extest_7497892c17ce4), el cual no tiene los permisos necesarios ni dispositivo móvil.

Opciones

Multiples y variadas:

  • Seleccionar credenciales de un buzón. .
  • Seleccionar nuestro Array. Que lo encuentre automáticamente.
  • Seleccionar un servidor en concreto. Nos referimos a un servidor con el rol de Client Access.
  • Especificar una URL de acceso al servicio ActiveSync.
  • Utilizar o ignorar Certificados.

Conectividad al buzón de un usuario dado a través del servicio de Autodiscover:

Test-ActiveSyncConnectivity -UseAutodiscoverForclientAccessServer -AllowUnsecureAccess -MailboxCredential (Get-Crendential)

En el caso de mi entorno tanto de pruebas como de producción este test me da siempre el mismo resultado ==> Forbiden, debido a la configuración particular del IIS que solo se puede acceder por certificado.

El resultado normal sería como el siguiente (imagen copiada del Blog ExchangeServerPro):

De todas maneras tenemos una herramienta bastante util para verificar y centrar los problemas con el servicio de ActiveSync: https://www.testexchangeconnectivity.com, desde un explorador podemos realizar todos estos chequeos:

Como ejemplo, un testeo de:

Aparece como erroneo porque necesita un certificado instalado en el cliente (está configurado en el servidor como “requerir” certificado). Todos los demas chequeos, correctos.

Un saludo,

Bibliografia.
Technet.
ExchangeServerPro.

Test-PowerShellConnectivity – Cmdelts de Testeo 12/32.

Seguimos con los  Posts sobre los cmdlets de testeo que tenemos en Exchange 2010 SP2 (aqui). Hoy Test-PowerShellConnectivity

¿Que realiza?

Nos realiza una prueba para comprar si la comunicación remota a través de Powershell con el servidor con el rol Client Access es saludable o no.

Test-PowerShellConnectivity


Podemos ver que se vuelve a utilizar el usuario de Test para realizar este chequeo de conectividad.

Opciones

Al igual que muchos de los cmdlets de test que hemos visto, sobre todos aquellos que son contra servicios en los servidores con el rol de CAS tienen las siguientes opciones:

  • Especificar credenciales de un buzón.-
  • Especificar un servidor con el rol CAS.-
  • Especificar el Directorio Virtual de Powershell.-

Comprobamos el directorio virtual de powershell en un servidor determinado utilizando TrustAnySSLCertificate para omitir la comprobación del certificado durante la conexión

Test-PowerShellconnectivity -ClientAccessServer ‘<Servidor>’  -VirtualDirectoryName ‘PowerShell (Default Web Site)’ -TrustAnySSLCertificate

Fijaros en la “enorme” la latencia de este chequeo…..

Ya queda menos, …., para todo.

Bibliografia.
Technet.

Test-WebServicesConnectivity – Cmdelts de Testeo 11/32.

Continuamos con los Posts sobre los cmdlets de testeo que tenemos en Exchange 2010 SP2 (aqui). Hoy Test-WebServicesConnectivity.

¿Que realiza?

Realiza un chequeo de la funcionalidad de los servicios web de Exchange mediante la ejecución de una serie de operaciones a través de Outlook Anywhere:

  • GetFolder.
  • CreateItem.
  • DeleteItem
  • SyncFolderItems

Test-WebServicesConnectivity

Podemos ver perfectamente las acciones que realiza, el resultado de las mismas (éxito en todas ellas) y el tiempo que tarda en realizarlas.

Opciones

Como ya hemos visto en la mayoría de los cmdlets de Test, podemos especificar servidores, usuarios, etc:

  • Especificamos un Servidor con el rol de CAS.-

 Test-WebServicesConnectivity -ClientAccessServer ‘<Servidor>’ | FT

Nuevamente podemos ver todos los procesos y la latencia de los mismos.

  • Especificamos un buzón a testear.- Introduciendo las credenciales

  Test-WebServicesConnectivity -MailboxCredential (Get-Credential) | FT

 Introducimos las credenciales a chequear:

Vemos el resultado, procesos y latencia de los mismos:

Os dejo con un ejemplo de error que he encontrado muy poquitos:

Que tengais buena semana.

Bibliografia.
Technet.

Test-OutlookWebServices – Cmdelts de Testeo 10/32.

Ya nos queda menos para terminar con los  Posts sobre los cmdlets de testeo que tenemos en Exchange 2010 SP2 (aqui). Hoy Test-OutlookWebServices.

¿Que realiza?

Verifica la disponibilidad de lo siguientes servicios de Exchange 2010:

  • Autodiscover.
  • Servicio de Disponibilidad
  • Outlook Anywhere
  • Offline Address Book (OAB).
  • Mensajería Unificada, aunque no esté instalada.

Test-OutlookWebServices


Opciones
Tenemos las sisguientes opciones básicas:

  • Especificar un servidor con el rol CAS en concreto.- Realizamos el chequeos de la situación de los servicios anteriormente indicados en un servidor con el rol de Client Access, entubando la salida a formato tabla:

 Test-OutlookServices -ClientAccessServer ‘<Servidor>’ | ft

  • Especificar las credenciales de un usuario.- Realizamos el chequeos de la situación de los servicios anteriormente indicados para un usuario, entubando la salida a formato tabla:

 Test-OutlookServices -Idenetity:rtejero@robezno.com | ft

Que tengais un buen lunes.
Nos vemos

Bibliografia.
Technet.

Test-ImapConnectivity – Cmdelts de Testeo 9/32.

Seguimos con los  Posts sobre los cmdlets de testeo que tenemos en Exchange 2010 SP2 (aqui). Hoy Test-ImapConnectivity, idéntico en funcionamiento al que vimos ayer Test-POPConnectivity.

¿Que realiza?

Nos realiza un chequeo del estado de  todos los servicios Windows necesarios para el buen funcionamiento del rol de Exchange que tiene instalado.

Test-ImapConnectivity

Opciones tenemos las mismas opciones que en otros cmdlets, pudiendo especificar un servidor con el rol CAS en concreto, unas credenciales que no sean del usuario de test, etc.

También podemos chequear si el puerto está abierto/cerrado mediante un telnet:

  • Puerto estandar.- Telnet 192.168.20.100 143
  • Puerto por SSL.-  Telnet 192.168.20.10 993

Que tengais buena Semana Santa.

Bibliografia.
Technet.

Test-PopConnectivity – Cmdelts de Testeo 8/32.

Continuando con la serie  Posts sobre los cmdlets de testeo que tenemos en Exchange 2010 SP2 (ver aqui). Hoy Test-PopConnectivity.

¿Que realiza?  Nos realiza un chequeo del estado del servicio de POP3 en el o los servidores con el rol CAS especificados.

Test-Popconnectivity

Opciones

Podemos especificar el servidor CAS sobre el que hacer el testeo e incluir unas credenciales distintas a las del usuario de test.

Test-Popconnectivity -ClientAccessServer <Nombre del CAS>  -MailboxCredential (get-credential <username>) | fl *


Si nos fijamos en el resultado, además de haber realizado el test con el usuario “ronin”, el servicio no está levantado en este servidor.

Otra opción, independiente de Powershell, que tenemos para comprobar POP3 es realizar un simple telnet al servidor y puerto:

  • Puerto estándar ==> Telnet 192.168.20.100 110
  • Por SSL ==> Telnet 192.168.20.10 995

Este chequeo no nos informaría del estado del servicio pero si del puerto.

Bibliografia.
Technet.

Test-OwaConnectivity – Cmdelts de Testeo 7/32.

Seguimos con esta serie de Posts sobre los cmdlets de testeo que tenemos en Exchange 2010 SP2 (ver aqui), empezamos con los testeos de los servicios que publicamos. Hoy Test-OwaConnectivity.

¿Que realiza?

Al igual que el que vimos ayer (aqui, Test-EcpConnectivity), el cmdlet de hoy nos realiza, por un lado, un chequeo del acceso al servicio Outlook Web App a todos los buzones que estén en un mismo Site de Directorio Activo, concretamente al directorio virtual creado en el o los servidores con el rol Client Access, y, por otro lado, nos puede realizar un test de conectividad para una URL individual de Outlook Web App. Lo vemos por partes,

Realizamos un test contra uno de los servidores con el rol CAS de nuestra organización:

Test-OWAConnectivity -ClientAccessServer <Servername>

Sobreescrito en rojo está nuestro servidor con el rol CAS y en azul, nuestro servidor con el rol MBX así como la URL interna de acceso a OWA. Si os fijais, ha vuelto a utilizar para realizar el test el mismo usuario que hablabamos ayer, extest_7497895c17ce4, al no haber especificado nosotros ninguna credencial.

Opciones

Si queremos realizar el test con unas credenciales distintas:

Test-OwaConnectivity -URL ‘https://mail.robezno.com/owa’ -MailboxCredential (Get-Credential <domainusername>)

Al igual que ayer con Test-ECPConnectivity y los cmdlets de test que veremos esta semana también podemos parametrizar si el  certificado es confiable o no. Para muestra un botón:

Test-OWAConnectivity –URL “https://emexch1.exchangemaster.me/owa” –MailboxCredential (Get-Credential <domainusername>) –TrustAnySSLCertificate

Mañana algo mas,

Bibliografia.
How Exchange Works.
Technet.