Automatizar la configuración con FC de una FlashArray //X en HyperV

Pues como el propio título indica, cuando hemos de hacer una configuración de una FlashArray //X en un entorno Hyper-V y mediante conexiones Fiber Channel, he creado un script en Powershell que automatiza el proceso de instalación y configuración, siguiendo las best practices que podéis encontrar en este enlace del centro de ayuda de Purestorage.

La verdad es que se podria hacer todo en entorno gráfico, pero mediante scripting es muchisimo más rápido y desatentido que no abriendo y cerrando ventanas de Windows. En todo caso, vamos a explicar los pasos de la configuración y el porqué de todo ello para, al final del post tener el script entero.

Instalación del MPIO (Multipath-I/O)

Esta característica de Windows se debe instalar para poder dotar al servidor o nodo Hyper-V distintas rutas (paths) hacia el almacenaje que presenta la FlashArray. Si uno de estas rutas (iSCSI o HBA) cae, la característica MPIO redirigirá las peticiones por otra ruta, sin que el acceso a los datos se vea afectado.

Configurar el MPIO

Una vez instalada la caracterísitca, se debe añadir el VendorId y el ProductID en un formato de 8 y 16 carácters para posteriormente, modificar los timers del MPIO para obtener el rendimiento óptimo en nuestra FlashArray. Los valores que se deben modificar son:

  • NewPathRecoveryInterval: es el tiempo que el servidor tarda en recuperar la ruta perdida. El valor por defecto es 40 y con FlahArray lo debemos cambiar a 20 segundos
  • CustomPathRecovery: es una variable booleana (1 o 0) que activa (1) o desactiva (0) la recuperación de la ruta personalizada, es decir, el primer parámetro que vamos a modificar. Con FlashArray el valor debe ser 1
  • PDORemovePeriod: un PDO es un objeto de dispositivos físicos (Physical Device Object). Este valor es el tiempo que espera el servidor a eliminar todas las rutas que han fallado hacia un PDO. El valor por defecto es 20 y con FlashArray lo debemos aumentar a 30
  • NewDiskTimeout: es el valor en segundos del tiempo de espera del disco. Este valor es el tiempo que esperará el servidor antes de marcar la solicitud E/S como fallida. En este caso se mantiene en 60 segundos, aunque la documentación de Microsoft lo establezca en 120
  • PathVerificationState: este valor nos indica si debemos verificar que el path está activo o no. Por defecto viene en Disabled y lo deberemos poner en Enabled

Configurar la política del MPIO

En este caso, y resumiendo, se refiere a como el servidor Hyper-V o host, distribuye las IOs entre las distintas rutas hacia el almacenaje. En este caso nos encontramos con que hay distintos tipos de politicas:

  • FOO: Fail Over Only
  • RR: Round Robin
  • LQD: Last Queue Depth
  • LB: Least Blocks
  • None: la que venga por defecto

En el caso de Pure Storage, la política de acceso debe ser Round Robin (RR)

Configurar la SAN Policy

Bàsciamente esto se refiere a como Windows Server determina si los discos deben montarse de forma automática cuando se detectan como nuevos en el host. En este caso si el host no forma parte de un Windows Server Failover Clustering, se debe cambiar la política de OfflineShared a OnlineAll para poner en linia los volúmenes existentes cuando se reinicie el host

Explicado todas las modificaciones que debemos hacer en un host Hyper-V, vamos a a ver como automatizarlo todo en un script. En primer lugar, los cmdlets que vamos a necesitar son los siguientes:

  • Instalación del MPIO (Multipath-I/O)

Get-WindowsFeature -Name 'Multipath-IO'

Add-WindowsFeature -Name 'Multipath-IO'

  • Configurar el MPIO

Remove-MSDSMSupportedHw -VendorId 'Vendor' -ProductId 'Product'

New-MSDSMSupportedHw -VendorId PURE -ProductId FlashArray

Set-MPIOSetting -NewPathRecoveryInterval 20 -CustomPathRecovery Enabled -NewPDORemovePeriod 30 -NewDiskTimeout 60 -NewPathVerificationState Enabled

  • Configurar la política del MPIO

Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR

  • Configurar la SAN Policy

Set-StorageSetting -NewDiskPolicy OnlineAll

Una vez tengamos claros los cmdlets con las opciones que Pure Storage nos recomienda para los entorns HyperV vamos a construir el script. Como punto de partida, debemos pensar que hay dos reinicios del host, y por lo tanto si quieremos que sea una configuración automática y desatendida, deberemos re-arrancar el script una vez arranque el servidor y nos logueemos de nuevo. Este script seguro que no es la mejor forma de hacerlo, pero es la que suelo usar yo en instalaciones desatendidas o semi-desatendias, siendo muy fácil su gestión.

El truco radica en crear un contador ($bootcount) que irá ejecuntando las opciones del menú switch {}, generando en un directorio %\temp un fichero *ps1 con las opciones y un fichero *bat que ejecutará el script. No soy programador profesional así que si encontráis fallos, estaré encantado de recibir vuestras (constructivas) críticas.

Script:

# Create a 'temp' Folder
if (!(Get-Item C:\temp -ea ignore)) { mkdir C:\temp }

$dropperscript = 'C:\temp\FlashArrayHV_Conf.ps1'

$dropper = @'

$countfile = 'C:\temp\bootcount.txt'
$bootbatch = 'C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\dropper.bat'
$dropperscript = 'C:\temp\dropper.ps1'

# Bootstrap Batch
if (!(Get-Item $bootbatch -ea ignore)) {
    "powershell -c $dropperscript`npause" | Out-File $bootbatch -Encoding 'OEM'
}

# Boot Count
if (Get-Item $countfile -ea ignore) {
    [int]$bootcount = Get-Content $countfile
    if ($bootcount -match "^\d{1,2}$") { ([int]$bootcount) ++ }
    else { $bootcount = 1 }
}
else { $bootcount = 1 }
$bootcount | Out-File $countfile

switch ($bootcount) {
    
    1 {
            Get-WindowsFeature -Name 'Multipath-IO'

            Add-WindowsFeature -Name 'Multipath-IO'
       
            Restart-Computer
                
    }
    
    2 {
            Remove-MSDSMSupportedHw -VendorId 'Vendor*' -ProductId 'Product*'
        
    New-MSDSMSupportedHw -VendorId PURE -ProductId FlashArray
            Get-MSDSMSupportedHw

            Restart-Computer
                
    }
    
    3 {
    
        Set-MPIOSetting -NewPathRecoveryInterval 20 -CustomPathRecovery Enabled -NewPDORemovePeriod 30 -NewDiskTimeout 60 -NewPathVerificationState Enabled
        Get-MPIOSetting
        Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR
        Get-MSDSMGlobalDefaultLoadBalancePolicy

        Set-StorageSetting -NewDiskPolicy OnlineAll
        Get-StorageSetting | Select-Object NewDiskPolicy
        Restart-Computer
     }
    
    default {
        # Dropper is complete; clean up
        rm $countfile
        rm $bootbatch
        rm $dropperscript
    }
}
'@

# Drop and run Dropper

$dropper | Out-File $dropperscript -Encoding 'OEM'

Invoke-Expression $dropperscript

VMWare: Unable to power on Virtual Machine

Buf…. maldito mensaje… y además ¡genérico! Bueno, en mi caso esta noche no podía arrancar una máquina virtual porqué me daba un error de un datastore que no estaba activo (lo peté del Datacore) pero aun estaba asociado a una máquina virtual.

El error que me daba era: Virtual disk ‘Hard disk 3’ is not accessible on the host: Unable to access file [VMFS Store Name] VM Name/VM Name.vmdk

Antes que nada, ¡calma! La solución es fácil y divertida de hacer Smile vamos a ello:

1) Primero lo que debemos hacer es (en caso de no tenerlo activado) arrancar el servicio SSH en el host donde tengamos la máquina virtual hospedada.

2) Editamos la máquina virtual y buscamos el disco vmdk que nos está dando problemas (y que muy probablemente no nos dejara remover así como así…) y vemos que en las propiedades el Virtual Device Node. Tomamos nota de él, en nuestro ejemplo SCSI (0:0) Hard disk 1

image

2) Nos conectamos mediante Putty al host y navegamos al siguiente directorio:

cd /vmfs/volumes/[Datastore donde está alojada la MV que no arranca]/[Nombre de la VM]

3) Una vez dentro, editamos el fichero vmx con el vi:

vi [Nombre de la VM].vmx

4) Vamos al final del fichero y buscamos las líneas que empiezan por el Virtual Device Node que nos hemos apuntado antes (en el ejemplo scsi 0:0) y las eliminamos. ¡Ojo! Solamente las que empiezan por scsi 0:0 o el valor que tengamos (suelen ser unas 4 o 5 líneas).

Nota: Para los que nos estáis familiarizados con el Putty, para editar el fichero pulsamos la tecla INSERT, eliminamos con SUPRIMIR y para guardar/salir pulsamos ESC y escribimos :wq!

5) Bien, cerramos el Putty y nos dirigimos a nuestro vCenter. Hacemos clic con el botón derecho sobre la máquina virtual que no arranca y le damos a Remove from Inventory. Esto lo hacemos ya que como hemos editado el fichero vmx, el host debe volver a leerlo.

6) Vamos al datastore donde tengamos la máquina virtual que no arrancaba, buscamos el fichero vmx y con el botón derecho seleccionamos Add to Inventory.

¡Y listo! Nuestra máquina virtual ya arranca pero esta vez sin el disco vmdk que nos daba problemas.

Error en xenserver SR_Backend_Failure_47

El otro día un cliente me llamó diciéndome que su sistema iba extremadamente lento. En un principio me acojoné un poco porqué este cliente funciona con Datacore SANsymphony en su versión 9.0 PSP4 (algún día hablaré del Virtual Storage) y con un sistema horrendo llamado Citrix XenServer.

Vale…supongo que ya habré herido algún sentimiento, pero pienso lo escribo: en mi particular ranking, este sistema ocupa el último puesto en cuanto a virtualización. No me gusta nada. Pero como tengo clientes que lo usan, debo saber aprender a manejarlo.

Siguiendo con lo que decía, mi cliente me llamó informándome que todo iba muy lento y cuando me conecté a la consola XenCenter, me fijé que todos los discos virtuales (a.k.a SR), habían perdido un path iSCSI hacia la V-SAN. (NOTA: los errores de multipathing son parecidos a la imagen siguiente, ya que podemos ver los dos servidores y en uno de ellos nos marca Connected y en el otro Unplugged)

¿Y ahora como los conecto? Bueno … pues tirando de manuales:

  • Hacemos clic sobre el servidor xenserver que ha perdido la conexión (NOTA: En un entorno multipathing, los servidores tienen varios caminos o path para acceder a los discos duros de la cabina) y pulsamos la pestaña “Console”

image

  • Veréis que es una consola Linux
  • En ella sacaremos primero de todo el error que nos da. Para ello, primero de todo buscamos el uuid (Universal Unique IDentifier) de nuestro SR asociado al host que ha perdido el path
[root@nuestroservidorxen]# xe sr-list
  • Cogemos el uuid del PBD (Physical Block Disk) asociado al SR anterior
[root@nuestroservidorxen]# xe pbd-list sr-uuid=<em>[Valor que nos a dado el comando anterior]</em>
  • Buscamos el parámetro que nos da el problema:
[root@nuestroservidorxen]# xe pbd-param-get param-name=other-config uuid=<em>[Valor que nos a dado el comando anterior]</em>

Bien, pues nos econtramos con un SR_Backend_Failure_47, que nos viene a decir que el servidor xenserver no se puede conectar con el recurso iSCSI. Dicho esto, debemos comprobar si realmente no existe comunicación entre el host i el recurso. Para ello haremos un ping a la interface de red del recuso iSCSI. Si NO responde, deberemos hallar el problema que muy probablemente será físico, pero si el ping responde, lo más seguro es que el problema sea lógico.

En nuestro error, el problema es lógico, ya que los ping responden sin problemas. Así mismo, para terminar de verificar el problema, podemos probar los siguientes comandos:

[root@nuestroservidorxen]# iscsiadm –m node

Con este comando veremos todos los IQNs disponibles y activos

[root@nuestroservidorxen]# iscsiadm –m session

Con este comando veremos todas la conexiones activas. Si no hay ningún error en ningún comando, entonces es que nuestro xenserver no se puede conectar al SR iSCSI (problema lógico). Pues ale, vamos a probar de conectarlos de nuevo…y lo haremos de dos formas. Pero ¡ojo! la/s máquina/s virtual/es asociada/s a este SR, deben estar apagadas.

Por consola:

root@nuestroservidorxen]# xe sr-list

[root@nuestroservidorxen]# xe pbd-list sr-uuid=<em>[Valor que nos a dado el comando anterior]</em>

[root@nuestroservidorxen]# xe pbd-plug uuid=<em>[Valor que nos a dado el comando anterior]</em>

Por el XenCenter

  1. Apagamos la/s máquina/s virtual/es asociada/s al SR que ha perdido la conexión
  2. Hacemos clic con el botón derecho sobre el SR que ha perdido la conexión y seleccionamos Detach con lo que desconectaremos el SR de todos los xenserver
  3. Hacemos clic con el botón derecho sobre el SR que hemos desconectado y seleccionamos Attach, con lo que podremos generar una conexión nueva

Si todo a ido bien, nuestro SR volverá a estar operativo con los dos (o los que sean) path iSCSI activos de nuevo.

Powershell: creación y eliminación de snapshots Hyper-V

índice

En un entorno virtual, es una muy buena práctica tener controlados los snapshots de nuestras máquinas virtuales. A diferencia de VMWare, en Hyper-V són puntos de control que se crean muy rápidamente y se consolidan de la misma forma. Es per ello que es una muy buena opción a contemplar como complemento de los backups.

En un caso concreto yo lo uso como estrategia de prevención contra Cryptolockers y ransomware varios haciendo que cada día, antes de que las empresas entren a trabajar se cree un punto de control. Para ello uso una tasca programada con el siguiente script:

Get-VM  * | checkpoint-vm -SnapshotName "[Nombre que le queramos dar] $((Get-Date).toshortdatestring())" –AsJob

Con este script en powershell, cada día se nos ejecutará un punto de control de TODAS nuestras máquinas virtuales. Podemos acotar la búsqueda o filtrar con el comando:

Get-VM –Name [Nombre de la M]

y que podremos filtrar. Por ejemplo: si todas nuestras máquinas virtuales se llaman SRV-[nombre] pero algunas son OLDSRV y solo queremos snapshots de las primeras, podemos hacer:

Get-VM SRV-*

Hecho esto, el siguiente paso es controlar cuantos snapshots queremos guardar. En mi caso solamente guardo un día puesto que como he dicho antes, es una medida de control contra los ransomware, no una backup. Para ello, uso el script siguiente:

Get-VMSnapshot –VMName [nombre_MV]* | Where-Object {$_.CreationTime -lt (Get-Date).AddDays(-1) } | Remove-VMSnapshot

Donde:

  • (Get-Date).AddDays(-1) son los días que quiero almacenar. En mi caso 1. Este valor lo podéis cambiar por el que queráis.
  • [nombre_MV]* es una string del nombre, como si fuera un sufijo. Es para filtrar.

De esta forma, puedo controlar que si nos entra algo que nos engorrine el sistema y es crítico, podemos en tan solo dos clics de ratón, volver al inicio del día. Eso si, para clientes o sistemas más críticos, uso el script varias veces al día y los elimino todos al día siguiente. La secuencia de comandos de la tasca programada es la siguiente:

powershell.exe –ExecutionPolicy Bypass –file “[ruta_del_script]”

Cambiar Win32Time a NTP

El otro día un cliente me comentó que tenía muchos problemas con la hora del servidor de dominio, y eso les daba muchos problemas. Revisando la instalación y configuración que tenía, me fijé que el PDC (Primary Domain Controller) no era el que subministraba la hora a los equipos del dominio, sino que lo hacía otro equipo mediante un ficherito bat. Esto claramente daba problemas, puesto que si el servidor que subministra la hora la pierde, arrastra con ello el resto de equipos.

¿Qué solución le propuse? Pues configurar que el PDC sirva la hora y que además no la sirva con el propio servicio Win32Time sino que lo haga como servidor NTP (mucho más estable).

Para ello, debemos ir a la siguiente clave del registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\

NTP_1

Debemos cambiar los valores siguientes:

  • El valor NtpServer les ponemos cualquier servidor NTP (en mi caso puse es.pool.ntp.org)
  • El valor Type cambiamos NT5DS a NTP

En la misma clave, pero en Config, cambiamos el valor AnnounceFlags de 10 a 5

image

Hecho esto, cerramos el regedit y abrimos un cmd en modo administrador y ejecutamos:

net stop w32time 

net start w32time

w32tm /resync /rediscover

Y testeamos la conexión con el siguiente comando:

c:\> net time \\[nombre_del_PDC] /set /y

¡Y listos! Nuestro servidor ya usará el sistema NTP para sincronizar la hora.

Error en la instalación de vSphere 6.0

Ya sé que hace mucho tiempo que no escribo nada interesante y me han llegado algún que otro mail, quejándose un poco de por qué tengo el Blog desactualizado. La verdad es que no dispongo de mucho tiempo y, cuando encuentro/soluciono alguna incidencia que quiero compartir con vosotros, pues me resulta imposible poderlo hacer. Así que, espere que (por enésima vez) pueda como mínimo escribir con cierta regularidad al respecto.

Dicho esto, os comento un reciente error (de hace algunos meses) que me daba la instalación del vSphere 6.0 como appliance. Los únicos vSphere que había instalado (en su versión 6.0) y por necesidades del guion, fueron sobre Windows Server 2012 R2 y la primera vez que lo instalé como appliance no paraba de darme errores en la instalación: Firstboot script execution error.

Pues bien, la solución la hallé aquí i la comparé en este blog, y la verdad la solución me dejó perplejo: solamente hay que añadir 1 solo registro DNS durante el proceso de instalación (a ser posible el del dominio) y si así persiste el error, añadir un registro DNS al controlador de dominio antes de la instalación (a mi me funcionó el primer paso).

Como comenta alguien en los foros de VMware…

vmware_please

Como reparar el error: “Servicio de perfil de usuario al iniciar sesion» en Windows 7

Este es un error (por desgracia) bastante frecuente en sistemas Windows Vista y Windows 7. Aunque nos parezca un «problemón» en verdad no lo es y su solución es muy simple.

NOTA: lo publico aquí porqué recientemente he visto que estos últimos días se han incrementado (sin comprender porqué) y, si puedo ser de ayuda, mejor 🙂

¡Al trapo!

  • Reiniciamos el PC/portátil en modo a prueba de fallos (Modo Seguro)
  • Ejecutamos la herramienta de registro de sistema REGEDIT pulsando la tecla Windows+R y escribiendo «REGEDIT»
  • Navegamos hacia HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList
  • Dentro veremos unos registros con un nombre del estilo S-1-5-20-93829738927189372891 y deberíamos ver uno de estos registros con una extensión .bak al final. Si hay varios de ellos, deberemos fijarnos que la numeración coincida (tomad como referencia la extensión .bak)
  • Pulsamos sobre el registro que no termina con .bak y, en el panel de la derecha si detectamos que en una de las keys pone C:\Users\Temp entonces debemos cambiar el registro.
  • Verificamos que en la que sí que termina en .bak una de las keys contiene el parámetro C:\Users\[nombre de usuarios] Si existe, este es el registro bueno.
  • Pulsamos F2 sobre el registro SIN extensión .bak y lo renombramos como .bak2
  • Pulsamos F2 sobre el registro CON extensión .bak y eliminamos la extensión
  • Pulsamos F2 sobre el registro CON extensión .bak2 y le borramos el 2
  • Cerramos el editor
  • Reiniciamos

Hecho esto, nuestro sistema iniciará sin problemas. Si por lo que sea, haciendo esto no nos arranca con normalidad, el problema será otro y deberemos averiguar de dónde viene la incidencia.

Powershell: ¿Cómo sé cuanto ocupan mis buzones en Office 365?

Pues eso: ¿cómo podemos saber cuanto ocupan nuestros buzones de Exchange Online en Office365?

De nuevo, usando Powershell y un script más que estupendo podemos obtener un fichero CSV donde  podemos ver el nombre de usuario, los elementos totales, el tamaño total del buzón en Gb, elementos en la bandeja de entrada y varios campos más 🙂 Importante! Debemos tener PowerShell actualizado a la versión 3.

Solamente copiad el script y guardarlo con la extensión *.ps1. Y recordad que antes de ejecutar el script tenéis que conectaros al Exchange:

  • Revisamos que la política sea «Unrestricted»
Get-ExecutionPolicy
Set-ExecutionPolicy Unrestricted
  • Nos conectamos y nos descargamos los cmdlet
$LiveCred=Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri &amp;lt;a href=&amp;quot;https://ps.outlook.com/powershell/&amp;quot;&amp;gt;https://ps.outlook.com/powershell/&amp;lt;/a&amp;gt; -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Y grabamos el script en un *.ps1.

#requires -version 3
[cmdletbinding()]
Param(
[Parameter(Position=0,
Mandatory=$false,
HelpMessage='Path of the CSV log file.')]
[String]$LogName = 'MailBoxes.csv'#,

#[Switch]$CountAllMailsItems

)

[System.Collections.ArrayList]$Mbx = @()
Write-Verbose -Message &quot;Searching for mailboxes...&quot;
$Mailboxes = Get-MailBox -ResultSize unlimited
[int]$i = 1
[int]$TotalMailboxes = $Mailboxes.count
Write-Verbose -Message &quot;$TotalMailboxes mailboxes found.&quot;

ForEach($MailBox in $Mailboxes){
Write-Progress -Activity &quot;$($MailBox.Alias)&quot; -Status &quot;Running&quot; -PercentComplete ([int]$($i/$TotalMailboxes*100))
Write-Verbose -Message &quot;$($MailBox.Alias)...&quot;
$i++

$MailBoxFolderStatistic = Get-MailboxFolderStatistics $MailBox.Identity -IncludeOldestAndNewestItems
$Calendar = $MailBoxFolderStatistic | ? {$_.FolderType -eq 'Calendar'}
$Contacts = $MailBoxFolderStatistic | ? {$_.FolderType -eq 'Contacts'}
$Inbox = $MailBoxFolderStatistic | ? {$_.FolderType -eq 'Inbox'}
$DeletedItems = $MailBoxFolderStatistic | ? {$_.FolderType -eq 'DeletedItems'}
$SentItems = $MailBoxFolderStatistic | ? {$_.FolderType -eq 'SentItems'}

&amp;lt;#
if($CountAllMailsItems){
$Mails = $MailBoxFolderStatistic | ? {($_.FolderType -eq 'User Created') -OR ($_.FolderType -eq 'Inbox') -OR ($_.FolderType -eq 'SentItems') -OR ($_.FolderType -eq 'Boite de récéption')}

[int]$ItemsInFolder = 0
ForEach($Folder in $Mails){
$ItemsInFolder += $Folder.ItemsInFolder
$FolderSize += $Folder.FolderSize
}
}
else{
$ItemsInFolder = &quot;N/A&quot;
$FolderSize = &quot;N/A&quot;
}
#&amp;gt;

$MailBoxStatistic = Get-MailboxStatistics $MailBox.Identity

$Mbx.Add([PSCustomObject][Ordered] @{
#Mailbox
Name = $MailBox.Name
TotalItems = $MailBoxStatistic.ItemCount
TotalSize = $MailBoxStatistic.TotalItemSize
#Mails
#TotalMail = $ItemsInFolder
#TotalMailSize = $FolderSize
SizeInMB = (($MailBoxStatistic.TotalItemSize.Value.ToString().split('(')[-1]).split(' ')[0]).Replace(',','') /1MB -as [int]
InboxItem = $Inbox.ItemsInFolder
InboxItemSize = $Inbox.FolderSize
LastReceive = $Inbox.NewestItemReceivedDate
FirstReceive = $Inbox.OldestItemReceivedDate
DeletedItems = $DeletedItems.ItemsInFolderAndSubfolders
DeletedItemsSize = $MailBoxStatistic.TotalDeletedItemSize
SentItems = $SentItems.ItemsInFolder
SentItemsSize = $SentItems.FolderSize
#Calendar
TotalCalendar = $Calendar.ItemsInFolder
TotalCalendarSize = $Calendar.FolderSize
#Contacts
Contacts = $Contacts.ItemsInFolder
#Divers
LastLogon = $MailBoxStatistic.LastLogonTime
Language = $MailBox.Languages
}) | Out-Null

$ItemsInFolder = $FolderSize = $MailBoxFolderStatistic = $Calendar = $Contacts = $Inbox = $DeletedItems = $SentItems = $MailBoxStatistic = $null
}
$Mbx | Export-Csv -NoTypeInformation -Delimiter ';' $LogName

Error en imprimir con Chrome: se quedan los documentos en la cola de impresión

Chrome Crash

Desde el pasado 27 de Agosto, se ha detectado que la última actualización de Google Chrome está dando problemas cuando queremos imprimir a través del navegador, quedándose los documentos en la cola de impresión. Esto sucede tanto si queremos imprimir a través del menú de Chrome o a través de código. De momento no hay una solución oficial y lo único que podemos hacer es cambiar la ruta del directorio temporal pues al parecer, la sandbox falla al no detectar la ruta correcta.

Esto se puede solucionar con un fichero batch:

echo off
md c:\gtemp\%username%\Temp
setx TEMP c:\gtemp\%username%\Temp
setx TMP c:\gtemp\%username%\Temp

En mi caso, al sucederme esto en un entorno Windows 2012R2, he creado un fichero *.bat y lo he forzado a que se ejecute al inicio de sesión de cada usuario, mediante el Logon script de las GPO. De esta forma el cambio se ejecuta en todos los UPD.

De momento no hay parche a la vista. En cuanto salga, actualizaré el post.

Fuente | Code Google

Microsoft Outlook: como recuperar la caché de contactos sin el fichero NK2

Un pequeño truquito para recuperar el ficherito de la memória caché del Outlook o en lo que en lenguaje coloquial se refiere, a la «lista de contactos que sale en el campo Para cuando pulso la letra a«, lo que el común de los trabajadores considera como su agenda del Outlook.

Bien, en primer lugar esto NO SIRVE PARA GUARDAR CONTACTOS! Simplemente es una cceso rápido a las direcciones de correo electrónico. Dicho esto, también hay que decir que Microsoft se ha puesto las pilas en cuanto a recuperar caché y demás (desde la versión 2010 la lleva incluida en el propio fichero PST), facilitando mucho las cosas con un Archivo -> Abrir -> Importar desde fichero PST.

Ahora bien, ¿que sucede cuando hemos actualizado un Outlook 2007/2010 a 2013 y el cliente dispone de Exchange? es decir, no existe fichero PST sinó fichero OST. Vamos a ello!

  • Navegamos hasta la ruta %APPDATA%\Local\Microsoft\Outlook\RoamCache
  • Aquí dentro deberemos encontrar unos ficheros con extensión *.SRS que empiezan por Stream_Autocomplete_0_XXXX
  • Debemos fijarnos en los tamaños: hay uno (el primero en teoria) que ocupa entre 1Kb y 2 Kb. Justo el sigueinte (en teoria) debe ocupar unos 100Kb o 200Kb. Este fichero es el bueno.

El engaño, el truco, la «magia»:

  1. Con el Outlook cerrado, movemos el segundo fichero en un directorio a parte (vamos a poner por ejemplo C:\backup-cache\
  2. Abrimos el Outlook y nos automandamos un mail. De esta forma se nos generarà un fichero nuevo Stream_Autocomplete_blablabla.srs
  3. Cerramos el Outlook
  4. Movemos este nuevo fichero a otro directorio (por ejemplo C:\backup-cache2\)
  5. Ahora, vamos al segundo directorio (C:\backup-cache2\) nos colocamos sobre el fichero, pulsamos F2 y copiamos el nombre entero del fichero.
  6. Vamos al primer directorio (C:\backup-cache\) nos colocamos sobre el fichero, pulsamos F2 y pegamos el nombre entero del fichero del segundo directorio. De esta forma tenemos un fichero SRS con toda la información pero con el nombre del nuevo fichero que ha generado el Outlook.
  7. Movemos este último fichero modificado a %APPDATA%\Local\Microsoft\Outlook\RoamCache.
  8. Abrimos el Outlook.

Si todo ha funcionado como debería, ya tendremos todo nuestro fichero de memoria caché recuperado. Recordad, este sistema es para recuperar la caché cuando el cliente dispone de un Exchange (en local o Online) y actualizamos la versión del cliente Outlook. En cuentas POP3 recuperando el PST ya nos basta.