viernes, 15 de noviembre de 2019

Los portátiles modulares y ampliables existen

Nos acercamos al Black Friday, y somos bombardeados con anuncios para renovar todo tipo de dispositivos, entre ellos, los portátiles. Nos encontramos las marcas habituales como Asus HP, Lenovo, Dell, Acer, todos ellos usualmente fotocopias cortados por el mismo patrón. Luego tenemos alguna excepciones, normalmente de marcas menos conocidas como MSI o Gigabyte, o de submarcas para un sector específico, Como OMEN, ROG, Razer, Alienware. Estas últimas, al ser de sector gaming, suelen ser como los equipos habituales, aunque con luces y colores llamativos caracteristicos del sector.

Al margen de todo esto se encuentra Apple, donde conserva una misma linea de productos desde tiempos de Jobs. Usualmente portátiles de potencia media, muy válidos para trabajo, y para juego casual.

Pero hay otra linea de portátiles, cada vez menos conocida (de hecho, las grandes marcas no tienen productos de este tipo en su negocio), conocidas como "superportátiles" o "estaciones de trabajo portátiles". Digamos que si lo puntero ahora son equipos como el LG Gram, que no llega al Kg de peso en 14" y sólo pesa 1,3 Kg en 17, aquí empezamos a ver equipos a partir de los 3 Kg. y usualmente a partir de las 15" en adelante.


Estos pesos, aparte de las dimensiones de las pantallas, vienen marcados por una peculiaridad: son equipos totalmente modulares. Cualquier componente es reemplazable, y son fácilmente ampliables. Y no quiero decir que puedas cambiar la RAM o el disco duro, donde algunos de los equipos convencionales ya no permiten ni eso, al venir soldados estos elementos a placa, sino que puedes, desde cambiar algo simple como la RAM, a montar un raid de discos de 2,5" o m2, pasando por un cambio de procesador, de tarjeta gráfica dedicada, de antena wifi, o bien agregarle una unidad grabadora de Blu-Ray.

Otra peculiaridad: igual que el 45% del mercado de placas base mundial pertenece a Asus, y otro buen porcentaje a Foxcomm, los fabricantes de estos equipo modulares se distinguen en tres grandes marcas: Clevo, Eurocom y TongFang. Vamos a ver quienes son.

Clevo

Es una empresa taiwanesa nacida en 1983, centrada en soluciones OEM para portátiles, tablets y pc´s todo en uno. Mantienen su premisa de equipos modulares, pero van más orientados a la portabilidad, aunque mantienen la potencia. Prácticamente casi cualquier máquina de su catálogo puede montar procesadores de última generación con 32 Gb de RAM.


Tienen un apartado íntegramente gamer donde se encuentran sus equipos más potentes. De hecho, es más fácil encontrar un equipo con la última tarjeta Nvidia, o con procesadores de 10ª Gen. de Intel, que en el catálogo de las grandes marcas del sector.
Sus equipos son más gruesos que los modelos de las grandes marcas, por lo comentado anteriormente, se sacrifica portabilidad por modularidad. También son unos equipos discretos en apariencia. Aunque dispongan de teclados retroiluminados, se pueden activar y desactivar (o configurar) a conveniencia, y no destacan las típicas teclas WASD.

Eurocom

Empresa canadiense ubicada en Ontario y fundada en 1989, se dedican al desarrollo de portátiles altamente configurables. En 2002 introdujeron el concepto de "estación de trabajo móvil", y siendo en la actualidad los únicos que montan procesadores de servidor en estructuras de portátil, creando los conceptos de "mobile server" y "superlaptop".


Si los equipos de Clevo son pesados, pero todavía más cercanos al portátil tradicional, en Eurocom podemos encontrar autenticas "bestias" de potencia y de peso, encontrándonos con máquinas de más de 5 Kg, pero con posibilidad de montar hasta 5 discos duros y 64 Gb de RAM.
Si bien la apariencia sigue siendo discreta, son algo más llamativos que los Clevo, bien por notas de color en las zonas de disipación de calor, o simple y llanamente, por las dimensiones de algunos modelos.

Tsinghua TongFang

Empresa china nacida en 1997, aunque fabrican una gama de productos electrónicos bastante variada, también producen componentes de ordenador y diseños de portátil.


Es difícil encontrar productos de esta marca en España, están más extendidos por Asia y el Este de Europa.

Pasamos a las distintas marcas que comercializan estos productos:

PCSPECIALIST
Esta empresa se fundó en 2003. Ensamblan los pedidos en Reino Unido y envían a toda Europa. Esta empresa, ademas ensambla también equipos sobremesa y todo en uno, aunque no ensamblan equipos tipo ultraportatil (la web está preparada para ofertarlos, pero no hay ningún modelo para configuración)
Tienen también el sello de Intel Premium Provider

OBSIDIAN-PC
No hay mucha información de su origen, fundación ni ubicación, pero parece que están ubicados en Portugal. Trabajan fundamentalmente con material de Clevo, pero están empezando a introducir portátiles de TongFang

NEXOC
Tambien nacida en 2003, de origen alemán y sede en Dachau. No especifican de dóne pertenecen sus modelos, pero por el diseño, que es lo que comparten todas las marcas, se aprecia que para los equipos ligeros los componentes son Clevo, mientras que los componentes para equipos Gaming de gama alta, son Eurocom.

MOUNTAIN
La primera marca reseller de este tipo que entró en España. Se dedican a modelos de portátiles y sobremesa, siendo los portátiles íntegramente Clevo. Junto con PCSpecialist, los únicos en España, al menos que haya visto.

CLEVOCENTER
Adivina de dónde provienen sus productos. Esta empresa, aunque es portuguesa, con sede en Lisboa, vende bastante al mercado español. Son bastante sobrios, al punto de no poner logotipo de su marca sobre los chasis genéricos.

Aparte de estas marcas centradas en Clevo y Eurocom, tenemos, tipo reseller de TongFang, las siguientes webs:

http://www.mechrevo.com

https://www.illegear.com/

https://www.cyberpowerpc.com/category/gaming-laptops

http://sklep.hyperbook.pl/

https://www.aftershockpc.com/welcome/Products

http://www.eluktronics.com/laptops/by-size/

http://www.assismatica.pt/categoria/tongfang_31236.aspx

http://www.inphtech.pt/

https://www.monsternotebook.com.tr/

https://www.monsterlabs.co.kr

Si, son unas cuantas, y con excepción de un par de tiendas portuguesas, el resto están demasiado lejos, y son demasiado poco conocidas como para analizarlas a fondo, aunque merece la pena darse una vuelta por sus configuradores para ver los modelos. Concretamente, los Mechrevo son bastante sorprendentes. Eso si, prepara el traductor de chino para la web.

¿Conoces alguna marca que venda productos de este tipo y no mencionados aquí? Por favor, ¡comentalo!

lunes, 4 de noviembre de 2019

Ejecutar EMCgrab en ESXi

ESXi es un fantástico producto, pero como todo, requiere chequeos para revisar su estado de salud, especialmente si hay algún caso abierto con EMC, donde te pedirán los informes EMCgrab.

EMCgrab es una pequeña herramienta por linea de comandos que se puede ejecutar prácticamente desde cualquier plataforma. Puedes descargarla para Windows desde ESTE enlace, aunque para acceder necesitas cuenta de usuario en EMC. Tambien puedes descargarlos de ftp.emc.com/pub/emcgrab/ESXi y ftp.emc.com/pub/emcgrab/ESX. El primero es para servidores ESXi, que son de 5.0 en adelante, y el segundo, para ESX.


El sistema es muy simple: el paquete descargado se descomprime. Dentro de la carpeta, verás un archivo "emcgrab.exe". Hay que ejecutarlo desde linea de comandos. El formato de ejecución es el siguiente:

Collect data connecting to ESXi server with ESXiGrab only
emcgrab.exe -host <esx host> -user <esx user> -password <esx password>
Collect data connecting to ESXi server with ESXiGrab only no prompting
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -autoexec -legal 
Collect data connecting to ESXi and vCenter servers using ESXiGrab and XtremeIO Host Validator
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -vcenter_server <vcenter server> -vcenter_user <vcenter user> -vcenter_password <vcenter password>

Collect data connecting to ESXi and vCenter servers using ESXiGrab and XtremeIO Host Validator with mixed non-XtremIO and XtremeIO storage
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -vcenter_server <vcenter server> -vcenter_user <vcenter user> -vcenter_password <vcenter password> -mixed_storage 
Collect data connecting to ESXi and vCenter servers using ESXiGrab and XtremeIO Host Validator with XMS connectivity
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -vcenter_server <vcenter server> -vcenter_user <vcenter user> -vcenter_password <vcenter password> -xms_name <xms server> -xms_user <xms user> -xms_password <xms password>

Collect data connecting to ESXi and vCenter servers using ESXiGrab and XtremeIO Host Validator with mixed non-XtremIO and XtremeIO storage and with XMS connectivity
emcgrab.exe -host <esx host> -user <esx user> -password <esx password> -vcenter_server <vcenter server> -vcenter_user <vcenter user> -vcenter_password <vcenter password> -xms_name <xms server> -xms_user <xms user> -xms_password <xms password> -mixed_storage

El siguiente comando ademas agrega el log bundle en el fichero generado de salida:

emcgrab.exe -host 172.19.4.56 -user <user>-password <password> -vmsupport -outDir <directorio de salida del fichero> -quiet

Si necesitas obtener el resultado en varios ESXi a la vez, puedes utilizar el siguiente script:

$user = 'root'
$pswd = 'XXXX'

Get-Content -Path hostnames.txt | %{
    emcgrab.exe -host $_ -user $user -password $pswd -vmsupport -party XXX -customer XXX -case XXX -contact XXX -phone XXXX -email XXXX
}

En el fichero .txt, un host por linea, sin espacios en blanco.

jueves, 24 de octubre de 2019

Solventar error en VDP: Operation failed due to existing snapshot

Un error que pasa con poca frecuencia, pero tarde o temprano aparece en VDP consiste en el fallo del backup avisando de la existencia de que hay un snapshot previo. Miras el Snapshot Manager, y  compruebas que no hay snapshots, y que no se puede consolidar la VM. Pero el error persiste:


¿Cómo puede ser que esté detectando un snapshot, si ya has verificado que no hay ninguno lanzado de forma manual, y a lo mejor incluso en VDP estás configurando la tarea por primera vez? Vale, configurando el backup por primera vez es imposible que pase, pero a lo mejor la máquina ha sido movida o copiada, o bien previamente tuvo respaldo de otro VDP, que son causas probables para el error.

Básicamente, lo que suele suceder es que algún archivo delta se queda enganchado en la VM, impidiendo su eliminacion y por tanto, su borrado y posibles backups posteriores. Veamos un ejemplo. Tenemos una VM con un solo disco.


Pero vamos al navegador de ficheros, y nos encontramos con esto:


Vemosque hay multitud de archivos delta que no deberían estar. Es mas, ni siquiera se utilizan, estan "perdidos", por decirlo de algun modo. De forma que podemos eliminarlos con la tranquilidad de que no vamos a perder datos por ello. En el caso de la imagen superior, eliminaremos todos los archivos que vemos ahora marcados, apagando previamente la VM.


Tras esto, podemos arrancar la VM, que funcionará sin problemas.

Como se ve en la imagen, también elimino, ademas de los archivos delta, los archivos de log y los .ctk. Es importante eliminar los archivos ctk, ya que contienen una lista de cambios producidos en la VM tras el último backup. Basicamente, contienen la informacion de los bloques de informacion que han cambiado, en vez de contener la informacion completa del disco. Solo debería haber un archivo ctk en la VM.

miércoles, 23 de octubre de 2019

Cómo conectar a Exchange Online con PowerShell

Ya sabemos que Microsoft quiere que administremos todo con PowerShell, y eso incluye sus servicios on-line. Y aunque el interfaz gráfico es muy cómodo, puntualmente se presentan tareas que es recomendable realizar via PowerShell, en lugar de pelearnos con los distintos menús de los sistemas de Azure.


En este caso, vamos a ver cómo realizar la conexión a Exchange Online PowerShell, ya que hay que realizar alguna configuración previa. Lo primero de todo, abrimos PowerShell como administradores.
Ejecutamos el comando  "Set-ExecutionPolicy RemoteSigned" para solicitar que lo que se descargue de Internet sea de confianza (esto vale con realizarlo solo una vez), y le pasamos nuestras credenciales con "$UserCredential = Get-Credential" (el nombre completo de cuenta, con el @xxx.com).


A continuación, realizaremos la conexión. Para ello, hay que tener primero en cuenta el requisito de proxy. Para ello, pasamos el siguiente comando primero, si vamos pro proxy. Si no, saltatelo:

$ProxyOptions = New-PSSessionOption -ProxyAccessType <Value
donde el valor "value" debe ser IEConfig, WinHttpConfig o AutoDetect, según lo que corresponda (siempre se puede cambiar el valor a posteriori, si te has equivocado al pasarlo.

Después pasamos el comando de conexion a Office365:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Si configuraste proxy, al final del comando debes agregar "-SessionOption $ProxyOptions" (sin comillas), quedando esto: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection -SessionOption $ProxyOptions

Ya solo queda por pasar el comando "Import-PSSession $Session -DisableNameChecking", sin comillas.


Dos últimos detalles:
- Al finalizar, ejecutar el siguiente comando para cerrar sesión: Remove-PSSession $Session
- Puede suceder que estés trabajando en un entorno híbrido. En ese caso, necesitas instalar un archivo desde tu centro de administracion de Exchange Online, en el apartado "híbrido".


Seleccionas la opción que corresponda, y autorizas la descarga. Para la implementación híbrida, el paquete que descarga es Microsoft.Online.CSE.Hybrid.Client.application.


Si da problemas, lanza la descarga desde Internet Explorer (todavía andamos así, Microsoft?).
Con esto, deberia ser posible realizar consultas y modificaciones de cuentas, asi como migraciones de un entorno a otro desde linea de comandos.

Para agregar el complemento de PowerShell, que puede ser lo que falte para determinados comandos, hay que instalar el módulo PowerShell:


Similar a la instalación del módulo híbrido, pero en vez de pedir la ejecución de una aplicación, ejecuta una ventana de PowerShell con las instrucciones de conexión:


Para verificar que la conexion ha sido realizada correctamente, basta con ejecutar en PowerShell el comando get-mailbox.
Para cualquier duda adicional, tenéis el enlace de Microsoft de ayuda en este ENLACE.

miércoles, 9 de octubre de 2019

Añadir listado de usuarios a grupo de Directorio Activo

Un va pequeño script (muy pequeño, realmente, apenas son 4 lineas) para agregar un listado de usuarios a un grupo de directorio activo.


Normalmente, con un simple copypaste de un excel al cuadro para agregar miembros al grupo valdria, pero cuando la cantidad de usuarios es masiva, la copia de miles de celdas no le sienta muy bien a la consola de AD, asi que mejor, con esta ejecucion de powershell:

Import-module ActiveDirectory $Fichero = Import-CSV "c:\ListadoUsuarios.csv" 
$Fichero.UserPrincipalName | ForEach-Object {        Add-ADGroupMember -Identity "nombredelgrupo" -Members $_
}
Solo eso. Desde Powershell ISE  pegamos estas lineas, que hacen lo siguiente:
En linea 1, importamos el modulo para trabajar con AD
Linea 2, Indicamos la ubicacion y nombre del fichero .csv con los usuarios.
Lineas 3 y 4, van agregando a los usuarios, uno por linea de excel.

Importante: El fichero .csv debe comenzar en la linea 1 con "UserPrincipalName", quedando asi:


No hay mas. Se puede hacer más complicado, se puede poner recuento de usuarios, pero, la verdad, en las pruebas hechas, no falla, asi que, ¿para qué complicarlo?

martes, 24 de septiembre de 2019

No se puede migrar una cuenta desde o365 a Exchange: Cannot find a recipient that has mailbox GUID


Cuando tratamos de migrar una cuenta de o365 a exchange en un entorno híbrido, esto es, donde tenemos Office365 y también un Exchange On-premise trabajando conjuntamente en el mismo entorno AD, obtenemos este error:

Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ‎'xxxxxxxx-xxx-xxx-xxxx-xxxxxxxxxxxx‎'. --] Cannot find a recipient that has mailbox GUID ‎'xxxxxxxx-xxx-xxx-xxxx-xxxxxxxxxxxx‎'.
 
Básicamente, esto sucede cuando el valor del GUID del buzón no está sincronizado en el buzón asociado en la organización local. El valor del buzón se almacena en la propiedad ExchangeGUID (también conocida como el atributo msExchMailboxGUID ) del usuario propietario del buzon. Para verlo, tenemos que ir al editor de atributos de la ficha de usuario.


Por suerte, la solución es simple: sólo hay que establecer el correcto valor GUID en el buzón remoto local asociado previamente a la migración del buzón. 

Para ello, nos vamos al shell de exchange del servidor local y ejecutamos el siguiente valor:

Get-RemoteMailbox usuario@midominio.com | Format-List ExchangeGUID


Puede pasar también que el GUID sea todo ceros, lo que significa que el valor directamente no se estampa en el buzón remoto local:


A continuación, nos vamos a Powershell. El comando a introducir para ver el GUID de la cuenta es muy parecido:

Get-Mailbox usuario@midominio.es| Format-List ExchangeGUID


Los valores, como veis, son distintos. En local teníamos un GUID terminado en 7cc6 (suponiendo que no os dé todo ceros) mientras que en Exchange Online termina, en este caso, en 7bbd.

Entonces, lo que vamos a hacer es establecer el GUID del entorno online, que es el que queremos migrar en este caso a local, en el entorno local. Para ello, volvemos al shell de Exchange local, e introducimos el siguiente comando:

Set-RemoteMailbox usuario@midominio.es -ExchangeGUID 8204ee3b-d483-45bd-97e6-e10d1a7b7bbd

Donde, si os fijáis, estamos poniendo el GUID que nos ha dado powershell, correspondiente a la cuenta online


Ya para terminar, podemos volver a realizar un get-remotemailbox, para asegurarnos que el cambio se ha aplicado

Una vez realizado esto, se puede volver a ejecutar desde Exchange online el proceso de migracion sin mayores problemas.

NOTA: Ten en cuenta que Exchange Online suele tener unos límites de almacenamiento bastante elevados para cuentas tipo E1 en adelante, y es posible que en local las database de almacenamiento de cuentas puedan estar limitadas, de manera que hay que tener cuidado de migrar a una database sin limite, o con un limite de tamaño de buzón inferior al consumido en o365.

jueves, 12 de septiembre de 2019

Cómo solventar el error 400 "bad name request" en Outlook Web Access

Trabajando con Exchange 2010 -2013 puede ocurrir que cuando se accede al mail via owa y accedes a las opciones del correo (arriba a la derecha), al pulsar “ver todas las opciones” para, por ejemplo, activar el automatic reply, sale la pantalla de selección de zona horaria y lenguaje:


Tras pulsar ok, da un mensaje de error 400, bad request.

Esto es debido a que el usuario no tiene definido un valor de zona horaria en el buzón de Exchange server 2010

Desde el servidor de Exchange, abrimos la consola, y podemos ver el valor configurado para la cuenta de usuario con Get-MailboxRegionalConfiguration -Identity “username” , sin comillas


En este caso, no se marca el campo lenguaje, lo que está ocasionando los problemas. Aplicamos la time zone y el lenguaje con el siguiente comando:

Set-MailboxRegionalConfiguration -Identity “nombredelbuzon” -Language "es-ES" -TimeZone "Romance Standard Time"


Una vez cambiado, volver a introducir el comando inicial, Get-MailboxRegionalConfiguration -Identity “username”, para verificar que se muestran los datos sin errores.

Si todavía tenias el buzon de owa abierto, haz logoff, logon de nuevo, y deberá estar funcionando sin problemas las opciones avanzadas.

miércoles, 11 de septiembre de 2019

Unable to reload module from vSphere: Solución

A partir de la version 6 de vCenter y, hasta donde llega mi conocimiento, la version 6.5 y sus distintas updates, puedes seguir accediendo al vCenter via plugin flash, con el enlace "https://<vcenter>/vsphere-client/?csp"

Y es posible que te encuentres con este mensaje:


Este mensaje aparece cuando se presenta una incompatibilidad de un modulo del vCenter con el idioma utilizado, en este caso, y  como se ve en la captura, el español.

La solución más lógica es dejar de utilizar el acceso web con plugin y empezar a utilizar la versión html5, aunque a veces sea complicado, no estando del todo fina hasta el update de vCenter a 6.7, o bien porque ya son muchos años los que hemos estado con la misma interfaz web con flash, y cuesta el cambio. Pero merece la pena probarlo, es solo un tema de estética, y hay que empezar a manejar la nueva interfaz. Para ello, entramos al vCenter con "https://<vcenter>/vsphere-client/ui"

Otro modo de entrar y operar sin el error consiste en deshabilitar el módulo problemático.
Entramos en el vCenter con la cuenta administrator@vsphere.local, vamos a los client plugins, y deshabilitamos le plugin del fallo.

La última manera de eliminar el fallo es cambiar el idioma por defecto del navegador, y acceder al vcenter indicando el idioma que queremos utilizar para evitar el error de carga de plugin en español. la dirección de acceso es https://<vcenter>/vsphere-client/?locale=en_US" . Con esto, le indicamos que queremos entrar con la configuración en inglés. Si quieres forzar la configuracion en español, cambias el "en_US" por "es_ES"

domingo, 25 de agosto de 2019

Solventar los problemas de la Security Update de Julio de 2019

Es posible que tras la actualización de Julio de 2019 (Monthly rollup) sobre equipos Windows 7 o Server 2008 R2 sp1 arrancando con UEFI, nos encontremos con que los equipos no arrancan mostrando un fallo del tipo "Info: An error has occurred while attempting to read the boot configuration data.", o bien "Windows cannot verify the digital signature for this file" provocando que el equipo no arranque y solo permita llegar a la pantalla de reparación.


Esto es debido a un error en los parches desplegados por Microsoft. Lo gracioso es que la actualización KB4512506 que causa el problema se lanzó el 13 de Agosto de 2019, y la solución está en la KB4512514, preview para la siguiente actualización, lanzada el 17 de Agosto. De manera que en vez de modificarse la monthly rollup, te puedes encontrar con que tus maquinas actualizadas a partir de las actualizaciones de seguridad mensuales, no arranquen, así que cuidadito con las updates del verano.

Si el problema que se muestra es que efectivamente tu equipo, con arranque UEFI arranca automáticamente a la ventana de recuperación del equipo, la solución consiste en reemplazar los ficheros winload.efi, winload.exe, winresume.efi y winresume.exe. Vamos a ello:
  • Desde la consola de recuperacion, vamos a la ruta donde tengas tu instalacion de Windows. Si es C:\, la ruta es c:\windows\winsxs\C:\windows\winsxs\
  • Entramos en la carpeta "amd64_microsoft-windows-b..vironment-os-loader_31bf3856ad364e35_6.1.7601.24499_none_b984965a9ca0bb23" sin comillas, todo seguido, sin espacios. Dentro de esta carpeta, veremos 4 archivos.
  • Escribimos "md c:\w" Cambiar la C por la unidad en la que se encuentre tu instalacion. Este comando creará un directorio con el nombre "w" en la raiz de c.
  • Escribimos copy . c:\w . Deberia mostrar "4 archivos copiados"
  • Seguidamente vamos a system32 con cd \windows\system32
  • Escribimos copy c:\w\*.* . Esto reemplazará los anteriores archivos. Puedes hacer previamente una copia de ellos
  • Salimos de la consola, y reiniciamos. 

Solo hay que seguir los pasos de la imagen superior. El equipo debería arrancar sin problemas.

Ah, un pequeño detalle: La carpeta donde se encuentran los 4 archivos corresponde a la copia de los mismos de Junio. Por tanto, se crearan en esa ruta distintos "backups" con lso que podemos afinar la restauracion a lo largo del tiempo, o en caso de no encontrar exactamente la ruta indicada más arriba.

miércoles, 21 de agosto de 2019

Tipo de disco no admitido o no válido para 'scsi0:0'. Asegúrese de que se haya importado el disco.

Para ponernos en situacion sobre la causa y resolucion del aviso "Tipo de disco no admitido o no válido para 'scsi0:0'. Asegúrese de que se haya importado el disco", os comento este ejemplo desde el inicio.


Vamos a instalar un Appliance cualquiera, en este caso, Zabbix, donde indican la descarga en un formato aparentemente válido, VMDK.


Me salto los pasos de descargar el archivo, descomprimir, crear la carpeta de la VM, subir los archivos al datastore y registrar la VM. Hasta aqui, todo perfecto. Es cuando arrancas la Vm cuando te encuentras con el error antes mencionado.

Basicamente, este error viene provocado por una incompatibilidad del archivo VMDK, no tanto por el formato, si es thin, thick, lazy zero, o cualquier otro formato, sino por la compatibilidad del VMDK con el producto de VMware que lo soporta. Me explico: muchas veces, estos archivos se generan pensando en las versiones más simples del producto, y por ello su formato es VMware Fusion, Player o Workstation. El producto ESXi es otra historia, y en este caso, es donde lo hemos subido, y donde la máquina falla a la hora de inicializarse.

Siempre que tratemos con appliances en este formato, la forma más simple de solventar este problema es realizar una conversion de formato a la vez que subimos el appliance a nuestro datastore. Para ello, utilizaremos VMware Converter.

Abrimos la aplicacion y pulsamos sobre Convert Machine.


Tenemos solo los archivos del appliance, no necesitamos poner la maquina en funcionamiento. Solo indicamos en las opciones, "Powered off", y marcamos el archivo de nuestro appliance.


Este paso es importante: indicamos que el destination type es VMware Infrastructure virtual Machine, no un vmware workstation o similar. Ponemos los datos para la conexión con nuestro vCenter (importante, el vCenter, no el ESXi).


Indicamos el nombre de la VM, y la ubicacion que debe tener, y next. Iniciará el despliegue de la VM. Tras esto, podreis arrancarla sin los problemas anteriores.

Después de todo esto, que en el fondo es un "workaround" en caso de encontrarte con este fallo, la moraleja es: si puedes, descarga el appliance en formato OVF (Open Virtualization Format), que no te dará tanta guerra y es fácilmente importable desde la consola de vCenter.

miércoles, 31 de julio de 2019

Habilitar copy-paste para la consola de VMware

Usualmente me conecto a las VM´s via Escritorio Remoto de Windows, pero hay que reconocer que la consola de VMware es cómoda para trabajar, sobre todo en primeras configuraciones, cuando todavia no está bien habilitada la red, por poner un ejemplo. Aunque se echa en falta la simple posibilidad de utilizar el portapapeles. El poder, en tu equipo, copiar por ejemplo un password complicado que debes introducir en la nueva maquina para lo que sea, o peor aún, debes ejecutar un script de cientos de lineas, y no tienes forma de pasarlo, con lo facil que sería con un coypaste.


Copypaste es una opción que originalmente existia en VMware, pero en la version 4.1 se deshabilitó, por problemas de seguridad. Por suerte, es facil habilitarlo, sólo tenemos que seguir los siguientes pasos:
  • Verificar que tenemos las VMware Tools instaladas. Si no es asi, ¡tienes un problema serio! ¡Son vitales! Instalalas sin falta.
  • Apagamos la VM, y vamos a la pestaña "summary". Ahí pulsamos sobre Edit settings.


  • Seguidamente, vamos a la pestaña "VM Options", en las opciones de la izquierda expandimos "Advanced", y pulsamos sobre "Edit Configuration"

  • Nos aparecerán los parámetros de configuración de la VM.Abajo, veremos la opción "add row". Tenemos que añadir los siguientes parámetros:


"isolation.tools.copy.disable", sin las comillas, y en valor, "FALSE", y otra linea mas con "isolation.tools.paste.disable" con valor "FALSE" igualmente, tal y como se ve en la imagen superior.
  • Pulsamos Ok, vamos cerrando los cuadros de dialogo, y ya está. SOlo queda arrancar de nuevo la VM.
Esta opción sólo modifica la VM sobre la que lo has hecho, pero puede ser que quieras activar estas opciones para toda tu granja de servidores. En ese caso, tendrás que modificar las opciones en el host ESX. Para ello, nos conectamos al ESXi como root, hacemos backup del fichero /etc/vmware/config antes de modificarlo, y seguidamente, lo editamos, añadiendo estas entradas al archivo:
vmx.fullpath = "/bin/vmx"
isolation.tools.copy.disable="FALSE"
isolation.tools.paste.disable="FALSE"
Tras esto, guardamos y cerramos el archivo.
Por cierto, la activación no es inmediata, se habilitarán cuando las VM´s se reinicien (o apagando y encendiendo, claro). Ten en cuenta también que si actualizas el host, habrá que volver a realizar los cambios.

miércoles, 12 de junio de 2019

Convertir una version de evaluacion de Windows en una Full Version

Como sabréis, podéis descargaros de la web de Microsoft la versión de evaluación de sus distintos productos, con un periodo de evaluación de 180 días (aunque luego explicaré como prolongar este estado de vida útil, y de manera totalmente legal). La versión de evaluación de Windows Server 2012, por ejemplo, la podeis descargar desde AQUI, así como los nuevos productos que están de camino, como la versión Server 2016.

Lo primero de todo: tu versión de Windows tendrá un aviso como este:


Siendo este el caso, lo primero que haremos será determinar con exactitud la versión de Windows que estamos utilizando. Para ello, abrimos una ventana de comando con privilegios de administrador, y ejecutamos el siguiente comando: DISM /Online /Get-CurrentEdition


Esto nos dirá la edicion que tenemos. Lo siguiente, será saber a qué ediciones podemos optar. Para ello, ponemos el comando DISM /online /Get-TargetEditions:


En este caso, y al ser un Datacenter Evaluation, solo nos da la opcion de actualizar a Datacenter. Pero si la version hubiera sido una Standar Evaluation, nos habria dado opcion de actualizar a una version Standar y a una Datacenter.

Bueno, ya tenemos nuestra version, y el nombre de la version a la que podemos actualizar. Ahora viene el paso en el que cambiamos la version, y el serial number que tengamos para la nueva version. El comando es DISM /online /Set-Edition: <el ID de la edicion, por ejemploServerDatacenter, sin los corchetes> /ProductKey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx /AcceptEula
Obviamente, ¡no pongas las X, sino tu serial number!


Este proceso requerirá dos reinicios. Aunque a veces, la máquina se queda frita por la tarjeta de red, y aunque cambia bien la versión del producto y el serial, no activa. Verifica que tienes conectividad, y dale otro reinicio, en caso de que no. A partir de ahí, es paciencia, o ir a activación, y decirle que active en el momento.

¡No tiene mas! Simple, rápido, y sin andar reinstalando Windows, como pide la versión de Evaluación cuando intentas ponerle una licencia Full Version

miércoles, 5 de junio de 2019

Flipboard ha sido hackeada

Según un comunicado que están recibiendo los usuarios de Flipboard, éstos han tenido accesos no autorizados a sus BBDD, aunque por los sistemas de seguridad que implementan, el riesgo de exposición de las contraseñas es nulo. Aun así, han reseteado todos los pass de acceso, de manera que en nuevos dispotitivos, cuando accedas a tu cuenta de Flipboard, te encontraras con un aviso para el cambio de contraseña. En cambio, en dispositivos donde ya estuvieras logueado, podras seguir accediendo sin problemas.


Adjunto el comunicado al completo:



Con todo esto, aun así, recomiendo el uso de esta herramienta para estar informado en todos los ámbitos que quieras, y perfectamente integrada para su uso en móviles y tablets.

Forzar vaciado de carpeta "Deleted Items" en Office365

Un pequeño problema observado con el trabajo en cuentas de Office365 consiste en el límite que éstas tienen en las carpetas creadas por defecto, como por ejemplo, deleted items. En este caso, el problema es causado por una limpieza del buzón de correo enviando más de 30 Gb a la papelera, y tras eso, forzar el borrado.

Aunque la carpeta nos da el mensaje de que no hay items contenidos en ella, se podían ver miles de mails contenidos. Esto es debido a la política de retención por defecto en la cuenta, que realiza el borrado definitivo e irrecuperable en un periodo de tiempo de 14 días.


Para solventar este problemilla, lo que podemos hacer es forzar la eliminación de los elementos. Aun así, la solución puede llevar 24 horas en aplicarse correctamente. Veamos los pasos a dar:

Abrimos Powershell como administrador local

Ejecutamos esto:
Set-ExecutionPolicy RemoteSigned

Seguidamente,
$UserCredential = Get-Credential

Las credenciales que ponemos son las de usuario administrador en office365, el login de acceso, que será un mail

Si tenemos un proxy, ejecutamos esto:
$ProxyOptions = New-PSSessionOption -ProxyAccessType <Value>

Donde Value será la configuración que necesites, en este caso,
$ProxyOptions = New-PSSessionOption -ProxyAccessType IEConfig

Las opciones posibles son IEConfig, WinHttpConfig o AutoDetect

A continuación, escribimos el siguiente comando:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 
https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic –AllowRedirection

Si has utilizado proxy, agregas al final -SessionOption $ProxyOptions. O sea, quedaría asi:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic –AllowRedirection -SessionOption $ProxyOptions
Si da error del este tipo,


Ejecutar el siguiente comando: Import-PSSession $Session –DisableNameChecking

Cargará el cmdlet, y probamos si funciona, con un get-mailbox “tubuzondecorreo”, asi, entrecomillado

Si aparecen los datos del buzon, introducimos el siguiente comando:

Set-mailbox “tubuzondecorreo” -RetainDeletedItemsFor 0

Seguidamente,

Start-ManagedFolderAssistant “tubuzondecorreo”

El proceso de vaciado de los deleted items puede llevar horas. Una vez finalizado, recordar cambiarlo de nuevo a 14 días, con:

Set-Mailbox “tubuzondecorreo” –retainDeletedItemsFor 14

En caso de querer examinar el progreso, puedes utilizar el siguiente comando:

Get-MailboxFolderStatistics usuario@dominio.com  | FT name,foldersize,ItemsInFolderAndSubfolders

para comprobar si el tamaño de "purges" va disminuyendo. Ademas, obtienes el listado detallado de ocupacion de las distintas carpetas. Si lo quieres en un documento de texto, al final del comando, agregamos un pipe (|) con el siguiente contenido:
Out-File -FilePath C:\larutaquequieras\nombredeldoc.txt

Si diera un problema de conexión, utilizar previamente este comando:

Start-ManagedFolderAssistant usuario@dominio.com
Si no, repetir todo el proceso para reconectar.

¡Y esto es todo!

jueves, 23 de mayo de 2019

Obtener un listado de números de serie y modelos de tus equipos

He aquí un pequeño script de Powershell para obtener, a partir de un listado previo de equipos en formato .txt, otro listado igual pero agregando a la lista el número de serie y modelo del equipo.


Ni que decir tiene que las máquinas, ya sean servidores o equipos, deben estar encendidas y accesibles desde tu red. Aquí va el script:

$file= "C:\listado.txt"
$inf = get-content $file
Out-File -FilePath C:\listadocompleto.txt -Append -InputObject "servidor;serial;modelo"
Foreach($server in $inf)

 {
$serial = gwmi win32_bios -computername $server |Select-Object -ExpandProperty SerialNumber
$model = Get-CimInstance -ClassName Win32_ComputerSystem -computername $server | Select-Object -ExpandProperty model


Out-File -FilePath C:\listadocompleto.txt -Append -InputObject "$server;$serial;$model"
}

Como ves, realmente el script ejecuta sobre cada una de las lineas del documento "listado.txt" los comandos gwmi win32_bios -computername, que te va los valores de versión de BIOS, fabricante, nombre de versión, Numero de Serie, y versión (que no es exactamente el modelo).


luego, al comando gwmi win32_bios -computername se le hace un "|" para indicarle que el único dato que queremos extraer es el SerialNumber. En la imagen superior puede ver los dos ejemplos, el comando ejecutado al completo, o sin la selección de SerialNumber.

Con la siguiente linea sucede lo mismo: tenemos Get-CimInstance -ClassName Win32_ComputerSystem -computername, que nos da una serie de valores como el nombre del equipo, propietario, dominio, memoria fisica, modelo (que es lo que nos interesa), y fabricante.


Igual que con el anterior comando, la primera parte nos da bastantes datos, y con el "|" agregamos el "Select-Object -ExpandProperty model" para obtener únicamente el modelo del equipo.

Finalmente, la ultima parte del script mete en un nuevo documento los equipos del listado inicial, y agrega el resto de campos solicitados.