Category Archives: Exchange 2010

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.