Category Archives: Test

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.

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.

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.

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.

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.

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.

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.

Buenos dias,

Continuando con la serie  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-ECPConnectivity.

¿Que realiza?

Como su nombre indica, nos realiza un chequeo del acceso al servicio Exchange Control Panel (ECP), concretamente al directorio virtual creado en los servidores con el rol Client Access. Es uno de los cmdlets de test que necesita una cuenta de «test» (esto ya lo viemos en este post). Este es el típico error que nos aparece en el caso de no tener dicho usuario de test:

Y estas son unas salidas típicas de este cmdlet de testeo, básico:
 

Opciones

Parámetros mas habituales:

• Incluir el nombre de un servidor con el rol CAS a testear. 

Test-ECPConnectivity –ClientAccessServer servername

• Seleccionar un servidor con el rol Mailbox (MBX) contral el que realizar el testeo.(si no seleccionamos ningún servidor MBX el test lo realizará contra todos). 

Test-ECPConnectivity –MailboxServer servername

• Podemos incluir la confinaza en certificados SSL,  

Test-ECPConnectivity –TrustAnySSLCertificate

• Así como testeo de las URLs, tanto internas como Externas:

Test-ECPConnectivity –TestType Internal

Si observamos este último test, aparece un error, concretamente no puede resolver el dominio, como se puede ver:

Una vez se crea una entrada DNS del tipo A, el problema se soluciona.

Bibliografia.
How Exchange Works.
Technet.

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

¿Que realiza?

La ejecución de este cmdlet valida la conexión de Outlook de un usuario. Este proceso de verificación, de extremo a extremo de la conexión, incluye verificar la conectividad de la detección automática (Autodiscover), crear un perfil de usuario e iniciar sesión en el buzón principal de un usuario, o buzón de archivo local o principal. Ademas, este cmdlet de test puede validar ambos tipos de conexiones de cliente, TCP/IP y Outlook en cualquier lugar. Si se produce un error en el cmdlet, el resultado muestra el paso en el que se produjo el error.

En este ejemplo simple podemos ver  los milisegundos de latencia que tenemos en cada proceso del test 

Test-OutlookConnectivity -Protocol:HTTP | ft Scenario,Result,LatencyInMillisecondsString

ademas, hemos definido el protocolo, HTTP, y la información a mostrar.

Opciones
Como principales opciones en este test tenemos las siguientes:

• Identity .- Especificamos un buzón determinado de destino.  
• GetDefaultsFromAutodiscover.- especifica si se obtienen los valroes predeterminados desde el servicio de Autodiscover.
• Protocol.- podemos seleccionar el protocolo: TCP/IP o HTTP.
• RpcAuthtenticateType.- especificamos el tipo de autenticación a probar, NTLM, Kerberos o Negotiate (que es el por defecto)
• RpcClientAccessServer.- Podemos especificar un servidor con el rol CAS para probarle.
• RpcTestType.- Podemos probar la dirección interna o la dirección externa.

Bibliografia.
Technet.

Buenos dias,

Continuando con la 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-MAPIConnectivity

¿Que realiza?

Nos realiza un chequeo del estado de la conectividad con nuestros clientes Outlook. Concretamente verifica la funcionalidad del servidor, el servicio RPC Client Access, asi como puede realizar un testeo de conectividad a un buzon determinado o a un servidor en concreto.

Si queremos comprobar la conectividad de un usuario de dominio:

Test-MAPIConnectivity -Identity «robezno»

El resultado es correcto.

Opciones
Si queremos realizar el chequeo contra una base de datos en concreto o a un servidor

Test-MAPIConnectivity -Database «TECNOLOGIA», o
Test-MAPIConnectivity -Server «ROBEZNOMBX001»

 Si queremos monitorizar eventos y contadores de rendimiento en la salida:

Test-MAPIConnectivity -Identity «robezno» -MonitoringContext $true

Nos vemos.

Bibliografia.
How Exchange Works.