Luchando por los MCPs

Después de varias horas de estudio y realizar algunos exámenes de Prometric recibí este correo de Microsoft:

De: mswwprog@microsoft.com
Enviado: sábado, 01 de diciembre de 2012 4:39:01
Para: XXXXXXXXXX

Congratulations on achieving your Enterprise Messaging Administrator on Exchange 2010 certification!

Ahora toca descansar y prepararme para actualizar el MCSE 2003 a 2008 que ya toca.

Accelerar arranque Exchange Management Shell

Cuantas veces nos hemos de pelear con los administradores de la cuenta para que nos “regalen” un servidor para poder hacer la administración, programar scripts/agentes, hacer el reporting automático… y después de conseguirlo vemos que al abrir el EMS (Exchange Management Shell) nos tarda 50 segundos o más en abrirse la consola… Un poco frustrante cuando estás testeando scripts para automatizar tareas.

Cansado de esto encontré en los blogs de msdn un post que indicaba como acelerar el arranque de Powershell. El script a ejecutar es el siguiente:

Set-Alias ngen ( Join-Path ([System.Runtime.InteropServices.RuntimeEnvironment ]:: GetRuntimeDirectory()) ngen.exe)
[ AppDomain]:: CurrentDomain .GetAssemblies () |
sort { Split-path $_ .location -leaf} |
%{
        $Name = ( Split-Path $_.location -leaf )
        if ([System.Runtime.InteropServices.RuntimeEnvironment ]:: FromGlobalAccessCache( $_))
        {
Write-Host "Already GACed: $Name"
        } else
        {
Write-Host-ForegroundColor Yellow "NGENing      : $Name"
            ngen $_.location | % {"`t$_" }
         }
      }

Para asegurarse que funciona correctamente mejor abrir la consola de powershell.exe en modo Administrador, es posible que el código posteado de errores por los saltos de línea con lo que mejor utilizar el enlace de descarga.

 Update-Gac.ps1

Con la ejecución de este código las dlls de powershell se cargan en la cache de ngen y se puede mejorar la ejecución de la consola en un 75%.

Creo que merece la pena!

Saludos

Cómo programar una desfragmentación offline en Exchange 2007

Por desgracia las ventanas de mantenimiento suelen ser a altas horas de madrugada para así no tener afectación a los usuarios y la tarea de hacer una desfragmentación al final se vuelve bastante tediosa ya que nosotros también nos merecemos dormir nuestras 6h 😛

Para poder lanzar la tarea y echarme a dormir hice este script en Powershell. El primer paso pide si hay que verificar si la bbdd está desmontada, puesto que si está enmedio de un backup daría problemas -y también porque me daba pereza programarlo para que fuera totalmente autónoma, la verdad sea dicha… Una vez desmontada la bbdd, el fichero edb se copia en otra ubicación distinta a modo de copia de seguridad y luego se lanza el eseutil /d.

Todos los comandos se guardan en la consola con lo que a la próxima verificación se puede verificar como ha ido la ejecución. A continuación tenéis el código:

#* FileName: MantenimientoBBDD.ps1
 #*================================================
 #* Script Name: [Mantenimiento BBDD Exchange]
 #* Created: [15/10/2011]
 #* Author: Xavier Rodriguez
 #*================================================
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin -ErrorAction SilentlyContinue
#*================================================
 #* Variables
 #*================================================
 $DatabaseName = "Servidor\sto_nombre_01\mdb01"
 #Introducir el nombre completo de la base de datos ej: Servidor/sto_storagegroup_01/nombrebbdd_mdb01
$Path_backup = "Z:\sto_tmp\"
 #Ruta de donde se hara la copia del edb antes del defrag
$edbfilename="MDB01.edb"
 #Nombre del fichero edb
$path_origen="T:\mdbs_01"
 #ruta del directorio origen del fichero edb
#*================================================
 #* Script Body
 #*================================================
 cls
 Write-Host "_______________________________________" -ForegroundColor Red
 Write-Host " DESMONTAR BBDD" -ForegroundColor White
 Write-Host "_______________________________________" -ForegroundColor Red
 Dismount-Database -Identity $DatabaseName -Verbose
 sleep 5
$title = ""
 $message = "¿Verificar si la BBDD esta desmontada y se puede proceder con las tareas?"
 $Yes = New-Object System.Management.Automation.Host.ChoiceDescription "&Yes", "Proceder con el copy y defrag."
 $No = New-Object System.Management.Automation.Host.ChoiceDescription "&No", "No proceder."
 $options = [System.Management.Automation.Host.ChoiceDescription[]]($Yes, $No)
 $result = $host.ui.PromptForChoice($title, $message, $options, 0)
 switch ($result)
 {
 0 {$OK=$true}
 1 {$OK=$false}
 }
if ($Ok -eq $true)
 {
$path = Get-MailboxDatabase $DatabaseName
 Write-Host "____________________________________________________________" -ForegroundColor Red
 Write-Host " COPIA BBDD EN UBICACION ALTERNATIVA" -ForegroundColor White
 Write-Host "____________________________________________________________" -ForegroundColor Red
 $run = 'robocopy.exe /B /R:10 "' + $path_origen + '" "' + $Path_backup + '" "'+ $edbfilename + '" '
 write $run
 sleep 5
 Invoke-Expression $run
 write-Host "___________________________________________________________" -ForegroundColor Red
 Write-Host " EJECUCION DEFRAG OFFLINE" -ForegroundColor White
 Write-Host "___________________________________________________________" -ForegroundColor Red
 $run = 'eseutil.exe /d ' + $path.EdbFilePath + ' /t ' + $Path_backup + 'temp.edb'
 write $run
 sleep 5
 Invoke-Expression $run
 Write-Host "_____________________________________________" -ForegroundColor Red
 Write-Host " MONTAR BBDD" -ForegroundColor White
 Write-Host "_____________________________________________" -ForegroundColor Red
 Mount-Database $DatabaseName -Verbose
 Write-Host "_____________________________________________" -ForegroundColor Red
 Write-Host " PROCESO FINALIZADO" -ForegroundColor White
 Write-Host "_____________________________________________" -ForegroundColor Red
 }else{
 write "Proceso abortado"
 }

¿Que meétodo utilizas para automatizarlo? Recuerda que las sugerencias siempre son bienvenidas.

Exchange Search no indexa tras actualizar a SP3

Poca documentación hay sobre Exchange Search y sobre qué hacer cuando hay un error en la indexación de una base de datos en Exchange 2007. Todo se remite a ejecutar el script de powershell ResetIndex.ps1 para así borrar los catálogos y forzar que se vuelvan a crear.

El otro día me encontré con que un servidor de buzones no indexaba el contenido tras tener que borrar temporalmente el catalogo de una bbdd por un problema de espacio. Una vez resuelto el problema de espacio y habilitada la indexación para esa bbdd, resulta que ésta no indexaba y que en las otras bbdd se visualizaba el típico mensaje de «Los resultados de la búsqueda pueden tardar mucho tiempo en aparecer, ya que la búsqueda de Microsoft Exchange no está disponible. Los resultados no incluirán las coincidencias del cuerpo del correo electrónico«.

Buscando en detalle el problema se pueden utilizar los contadores de rendimiento:

  • MSExchange Search Indices
    • Age of Last Notification Indexed
    • Age of Last Notification Processed
    • Average Latency of RPCs during Crawling
    • Average Latency of RPCs to get Notifications
    • Average Latency of RPCs used to Obtain Content
    • Number of Create Notifications
    • Number of Content Conversion Done
    • Number of Documents Successfully Indexed
    • Number of Documents that failed During Indexing
    • Number of Failed Retries
    • Number of Indexed Attachments
    • Number of HTML Message Bodies
    •  Number of RTF Message Bodies
    • Number of Outstanding Batches
    • Number of Outstanding Documents
    •  Number of Plain text message Bodies
    •  Number of Update Notifications
  • MSFTESQL-Exchange:Catalogs
    •  Batches Completed Success
    • Batches Completed w/errors
    •  Batches Completed w/warnings
    •  Batches done
    •  Batches in Progress
    •  Batches Received
    •  Trans in Progress

[Podéis encontrar más información sobre esto en el blog de Roopesh Pattan].

Tras hacer el seguimiento del problema y ver que en todas las bbdd no se indexaba ningún elemento correctamente, se podía ver en los contadores cómo solamente aumentaba el “Number of Documents that failed During Indexing”. También estuve revisando las Notas de los parches de Exchange tras el SP3 y en ninguna se hace referencia a dicho problema… Pero finalmente encontré la solución.

Parece ser que por algún motivo desconocido -o no publicado- con el SP3 de Exchange 2007, el .NET de Microsoft Framework SP2 hace unas verificaciones en el CRL (Certificate Revocation List) que están disponibles en http://crl.microsoft.com, y que si está URL no devuelve ningún mensaje, el servicio de Indexación deja de funcionar correctamente…

LA SOLUCIÓN:

Tener internet en el servidor de buzones o crear una entrada en el fichero HOSTS con la siguiente información:

127.0.0.1              crl.microsoft.com

Una vez guardado el fichero hay que reiniciar el servicio Microsoft Search Indexer y luego sólo nos quedará observar cómo, para nuestra alegría, el contador “Number of Documents Successfully Indexed” empieza a aumentar.

¿Te ha servido?