No se si alguien habrá tenido que eliminar algún buzón desconectado en Exchange Server 2007, pero desde la consola gráfica ya no es posible ejecutar esta acción. Lo que en Exchange Server 2003 se resolvía con un simple clic en purgar con el botón derecho en el buzón desconectado que queriamos eliminar, lo cierto es que con Exchange 2007 la cosa se ha complicado un poquito.

Para empezar tenemos que averiguar el GUID del buzón, para ello ejecutamos lo siguiente:

• Get-MailboxStatistics | where-object { $_.DisconnectDate -ne $null } | Select DisplayName,MailboxGuid

Ahora borramos el buzón haciendo referencia al GUID

• Remove-Mailbox -Database <Database-Name> -StoreMailboxIdentity <MailboxGuid> -confirm:$false

Tambien podemos seleccionar un grupo de buzones, guardar el resultado en una variable y eliminarlos todos en un solo paso

• $buzones = Get-MailboxStatistics | where-object { $_.DisconnectDate -ne $null } | Select DisplayName,MailboxGuid
• $buzones | ForEach { Remove-Mailbox -Database "Mailbox Database" -StoreMailboxIdentity $_.MailboxGuid -confirm:$false }

Otra de las tareas que no se exponen en la consola gráfica es la actualización de la lista de buzones desconectados (lo que conocíamos como agente de limpieza en Exchange Server 2003). Para ello debemos ejecutar el cmdlet clean-mailboxdatabase <Nombre_de_base_de_Datos>.

Gracias a Anderson Patricio por la información. Saludos y hasta el próximo post.

Este cmdlet exporta la infromación de lo que ha sucedido en un periodo de tiempo determinado con los mensajes entrantes. En la lista se incluye información de la acción realizada y el nivel SCL que el agente a impuesto.

• Get-AgentLog -StartDate "01/04/2008 00:01:00" -EndDate "30/04/2008 23:59:00" | ft timestamp,IPaddress,P1FromAddress,recipients,action,reason,reasondata | out-String -Width 180 > C:\MensajesFiltrados_SCL.txt

Como podéis observar, los parámetros StartDate y EndDate determinan el intervalo de datos, mientras que ft (format-table) formatea la salida para sólo mostrar los campos que queremos, que en este caso son la Fecha, Dirección IP del remitente, Dirección SMTP del remitente, Destinatarios, Acción realizada por el agente, Motivo, Valor SCL. Por último establecemos el tamaño de las columnas para evitar que se corten datos y lo enviamos a un fichero de texto.

 Un abrazo.

Exchange Server 2007 incluye una característica muy interesante que se llama Autodiscover. El aplicación Autodiscover permite configurar automáticamente el perfil de Outlook 2007, incluyendo el acceso Outlook Anywhere, POP3 o IMAP. Todo lo que tiene que hacer el usuario es ingresar en el asistente de creación de perfil su dirección de correo electrónico y su contraseña. Entonces el servidor localiza el buzón del usuario y envía la configuración de todo el perfil mediante XML al cliente Outlook.

Hasta aqui todo muy bien, el problema surge cuando queremos hacer uso de certificados de seguridad propios para el acceso seguro a OWA, ActiveSync o Outlook Anywhere. Habitualmente la aplicación Autodiscover va a estár ubicada en el rol de Acceso de Cliente (Client Access Server), junto con el resto de servicios. Sin embargo, el cliente Outlook por defecto utiliza un canal seguro para consultar a autodiscover, además lo hace haciendo referencia a dominio.com o autodiscover.dominio.com (dominio.com equivale al dominio de la organización).

Si el certificado que hemos emitido para los servicios de movilidad es por ejemplo correo.dominio.com, entonces cada vez que habramos Outlook obtenderemos un mensaje de advertencia:

Esto sucede por la diferencias en el nombre del servicio que se está consultando.

Para resolver este problema es necesario generar un certificado que admita multiples nombres de dominio o host. Esto lo podemos hacer con el Shell de Exchange 2007:

Primero generamos la solicitud de certificado que posteriormente vamos a enviar a la CA (Entidad Certificadora). Es importante agregar todos los nombres de host y de dominio que se vayan a utilizar, incluyendo dominio interno y público en caso de que sean distintios. También se debe agregar el nombre NETBios del servidor

• New-ExchangeCertificate -generaterequest -subjectname "dc=com,dc=dominio,o=Empresa S.A,cn=webmail.dominio.com" -domainname srvhub,srvhub.dominio.org,dominio.com, webmail.dominio.com,autodiscover.dominio.org, autodiscover.dominio.com -PrivateKeyExportable $true -path c:\certrequest_srvhub.txt

Una ver realizado esto, debemos enviar la solicitud a la CA a través de su página Web y seleccionar la plantilla Web en la solicitud avenzada.

El certificado emitido lo descargamos y lo utilizamos para importarlo a Exchange Server 2007 y lo habilitamos para los servicios IIS, POP e IMAP:

• Import-ExchangeCertificate -path <certificate_file_name>.cer -friendlyname "Certificado servicios de correo | enable-exchangecertificate -services "IIS,POP,IMAP" 

Ahora el certificado será válido para todos los dominios y nombres de Host que se hemos especificado en la solicitud.

Saludos y hasta el próximo artículo.

En alguna ocasión necesitaremos otorgar permiso de acceso completo a una cuenta sobre un buzón determinado. Un escenario común para esto es el acceso secretaria / directivo, o el acceso de cuentas de servicio como BES (Blackberry Enterprise Server).

Pues bien, algo que en Exchange Server 2003 se podía realizar mediante las propiedades del buzón en la consola Usuarios y Equipos del Directorio Activo, ahora con Exchange Server 2007 se debe configurar mediante PowerShell. El cmdlet es muy sencillo y otorga los mismos privilegios que en la versión anterior, es decir, en realidad lo que hace es modificar los derechos sobre el objeto buzón del Directorio Activo.

• Add-MailboxPermission -Identity <Alias_del-Buzon> -User <Cuenta_de_usuario> -AccessRights FullAccess

Este simple cmdlet otorga permiso Full Access a la cuenta <Cuenta_de_usuario> sobre el buzón <Alias_del_buzon>. Sin embargo si queremos aplicar este permiso a un grupo de buzones o incluso a todos los buzones de la organización, podemos hacer consultas de objetos que después pasaremos mediante una tubería (pipe), en estos casos ya no sería necesario establecer el atributo -identity.

• get-mailbox -OrganizationalUnit <Nombre_OU> |  Add-MailboxPermission -User <Cuenta_de_usuario> -AccessRights FullAccess
• get-mailbox -resultsize 500 | Where {$_.customAttribute1 -Match "Comerciales"}  |  Add-MailboxPermission -User <Cuenta_de_usuario> -AccessRights FullAccess

Cuando iniciamos sesión en OWA 2007, de forma predeterminada, el idioma del formulario está en inglés. Si queremos cambiar el idioma del inicio de sesión y de las páginas de errores en Exchange Server 2007, debemos configurar lo siguiente en PowerShell

• Set-OwaVirtualDirectory -LogonAndErrorLanguage 3082 -Identity "<NOMBRE_DEL_SERVIDOR>\owa (sitio Web predeterminado)"

3082 corresponde al código de Locale ID (LCID) de productos Microsoft. La lista completa la podeis encontrar aqui:

• http://www.microsoft.com/globaldev/reference/lcid-all.mspx

Para saber como se está comportando nuestro servidor perimetral (Edge transport) con respecto a los niveles SCL (Spam Confidence Level) en un periodo determinado, podemos extraer un pequeño informe con el siguiente cmdlet:

• Get-AgentLog -StartDate "dd/mm/aaaa hh:mm:ss" -EndDate "dd/mm/aaaa hh:mm:ss" | ft timestamp,IPaddress,P1FromAddress,recipients,action,reason,
  reasondata | out-String -Width 180 > C:\listaSCL.txt