viernes, 26 de abril de 2019

AWS - Subir on premise VM a AWS.


Hola,

En el siguiente artículo, os voy a explicar como subir una máquina virtual que tenemos corriendo on premise a AWS, así como particularidades que he observado y aportes respecto al procedimiento oficial que podéis encontrar aquí:

https://docs.aws.amazon.com/es_es/vm-import/latest/userguide/vmimport-image-import.html

Y más extensamente aquí:

https://docs.aws.amazon.com/vm-import/latest/userguide/vm-import-ug.pdf

AWS Server Migration Services o Import/Export
Antes de nada, cabe destacar que desde que ha aparecido el proceso de migración de máquinas virtuales (AWS Server migration services) el proceso que aquí detallo, es idoneo si has de crear una plantilla para luego, crear diferentes máquinas virtuales. Este proceso también vale y hasta la fecha se utilizaba, para migrar tus máquinas virtuales, pero ahora que podemos elegir, AWS Server migration Services facilita enormemente la migración.

Requsitos en vuestro equipo
Previo a la realización del proceso, es necsario que instaléis AWS command line

https://aws.amazon.com/es/cli/

Requisitos de la VM
También, antes de apagar la máquina on premise y empezar a trabajar la migración hacia AWS, debéis leer el siguiente link, donde os dicen como preparar la máquina previo a la subida.

https://docs.aws.amazon.com/es_es/vm-import/latest/userguide/vmie_prereqs.html

En relación al formato de discos soportados, aquí AWS gana, porque soporta todos los formatos de discos virtuales y además, en referencia  Hyper-V, soporta discos VHD, VHDX bien sean estáticos o dinámicos.

Es importante que siguiendo el link de pre requisitos antes expuesto, sigáis los pasos para preparar la máquina en el apartado "Prepare su máquina".

Migración

Vamos allá. Los pasos para la migración son los siguientes:

1. Abrir CMD y conectar a vuestra suscripción en AWS con el comando AWS Configure.

2.Empezar a subir el disco de la VM a un Bucket. Para poder subir un archivo grande debéis utilizar la línea de comandos. El comando es el siguiente:

AWS s3 cp  "origen" s3://nombredebucket.

Ejemplo:
3. En paralelo, mientras subimos el disco, debéis crear un archivo, con nombre trust-policy.json con el texto siguiente y ejecutar el comando que os detallo también.

Texto:
{
  
"Version": "2012-10-17",
  
"Statement": [
      {
        
"Effect": "Allow",
        
"Principal": { "Service": "vmie.amazonaws.com" },
        
"Action": "sts:AssumeRole",
        
"Condition": {
           
"StringEquals":{
              
"sts:Externalid": "vmimport"
            }
         }
      }
   ]
}


Comando:  aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json



4. Creemos ahora un archivo con el cliente texto y nombre role-policy.json

4.2 Tenemos que lanzar el archivo con el comando: aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document file://role-policy.json

Es necesario que sustituyas "Disk-image-file-bucket" con el nombre del bucket. (Ver ejemplo).
{
  
"Version":"2012-10-17",
  
"Statement":[
      {
        
"Effect":"Allow",
        
"Action":[
           
"s3:GetBucketLocation",
           
"s3:GetObject",
           
"s3:ListBucket" ], "Resource":[
           
"arn:aws:s3:::disk-image-file-bucket",
           
"arn:aws:s3:::disk-image-file-bucket/*"
         ]
      },
      {
        
"Effect":"Allow",
        
"Action":[
           
"ec2:ModifySnapshotAttribute",
           
"ec2:CopySnapshot",
           
"ec2:RegisterImage",
           
"ec2:Describe*"
         ],
        
"Resource":"*"
      }
   ]
}
Ejemplo:

5. Ahora tenemos que importar el disco ya subido (supervisar la copia lanzada en el paso 2. 
Para ello tenemos que crear un nuevo archivo json, con el nombre "containers.json".

Texto:
[
  {
   
"Description": "NOMBREDESCRIPTIVO",
   
"Format": "vhd",
   
"UserBucket": {
       
"S3Bucket": "my-import-bucket",
       
"S3Key": "vms/my-windows-2008-vm.ova"


    }
}] *formato: vhd, VMDK, RAW, OVA, ETC. Comando: aws ec2 import-image --description "NombreDescriptivo" --license-type --disk-containers file://containers.json A tener en cuenta que los valores posibles de --license-type son:

  • Auto (valor predeterminado)
    Detecta el sistema operativo (SO) del sistema de origen y aplica la licencia adecuada a la máquina virtual (MV) migrada.
  • AWS
    Reemplaza la licencia del sistema de origen por una licencia del AWS, si procede, en la MV migrada.
  • BYOL
    Conserva la licencia del sistema de origen, si procede, en la MV migrada

https://docs.aws.amazon.com/es_es/vm-import/latest/userguide/vmie_prereqs.htm

Ejemplo:

Comando:

AWS ec2 describe-import-image-task

Con este comando, podréis ver el estado de la migración de vuestro disco a imagen AMI. Los estados son:

  • active — Ta tarea de importación esta en curso.
  • deleting — La tarea de importación se está cancelando.
  • deleted — La tarea de importación se ha cancelado.
  • updating — El estado de la importación se está actualizando.
  • validating — La imagen importada se está validando.
  • validated — La imagen importada se ha validado.
  • converting — La imagen importada se está convirtiendo en una AMI.
  • completed — La tarea de importación se ha completado y la AMI está lista para usar.

https://docs.aws.amazon.com/es_es/vm-import/latest/userguide/vmimport-image-import.html 5. Una vez finalice este proceso, pasáis a tener ya una AMI, que no es más que una plantilla lista para el despliegue.
6. Elegir la imagen y hacer click en Select para el despliegue.


miércoles, 24 de abril de 2019

Redirigir los equipos incluidos en dominio a una OU específica.

Hola,

Es bien conocido que la carpeta (ya que no es una OU), con el nombre Computers a la que van los equipos una vez los añadimos en el dominio, no es muy práctica ya que no permite asociar GPOs y además, solemos querer que los equipos vayan a otra OU creada por nosotros.

Pues bien, siempre ha existido un comando que varía ese comportamiento por defecto y nos ahorra, tener que pasar por el AD de vez en cuando para mover los nuevos equipos, los cuales, llevan unos días trabajando sin las GPOs pensadas para ellos.

Pues bien, el comando es: REDIRCMP

Y un ejemplo sería este:

REDIRCMP OU=OUdeseada,DC=Dominio,DC=local 

Espero que os sea de ayuda.

Saludos.

viernes, 19 de abril de 2019

Google Cloud - Subir Hyper-V VM on premise a Google Cloud.


Hola,

A continuación os voy a detallar el proceso para subir una máquina virtual que tenéis corriendo en On premise sobre Hyper-V a Google Cloud.

En este procedimiento, partimos de un a configuración donde ya habéis creado un Proyecto y un Segmento de almacenamiento en vuestra suscripción.

También tenéis que tener instalado Google Cloud SDK https://cloud.google.com/sdk/docs/ y tener ciertas nociones del mismo para poder establecer la conexión y acceso a vuestra suscripción y proyecto.

Cabe destacar también que tenéis que convertir vuestro VHDX si así lo tuvieseis, en VHD y para ello, conviene que leais el post que escribí reciéntemente.  http://undercpd.blogspot.com/2019/04/a-continuacion-os-detallo-cosas-tener.html

Una vez tenéis el VHD que contiene el C: de la máquina virtual tenéis que seguir estos pasos:

1. Habilitar en vuestra cuenta de Google cloud el CLOUD BUILD API.  de no habilitarlo, durante el proceso de creación de la imagen (Paso 5) y tras bastante minutos copiando el contenido de un espacio de almacenamiento a otro, os preguntará si lo queréis habilitar, pero el proceso de creación de la imagen propiamente fallará, ya que habilitarlo tarda unos minutos y el proceso de copia da un error que a la postre es un time out. Por ello es conveniente que lo habilitéis previamente, o bien, sepáis que el proceso de conversión de la imagen, lo tendréis que lanzar por segunda vez.

2. También es conveniente que sepáis los permisos que se van a configurar automáticamente.



Avisos a aceptar durante el proceso de copiado si no habéis habilitado previamente Cloud build api


3. Ahora, utilizando Google cloud sdk, vamos a abrir la linea de comandos, conectarnos a nuestra suscripción y utilizar el comando GSUTIL, el cual nos permitirá subir el archivo VHD a Google cloud.  Tened en cuenta que el copiado del VHD vía web, falla dado el tamaño del archivo.

  • gsutil cp [LOCAL_OBJECT_LOCATION] gs://[DESTINATION_BUCKET_NAME]/
  • Ej:  Gsutil cp c:\vms\archivo.vhd gs://zrkvms


4. Vamos a crear una imagen, procedente de ese VHD . Tras tener esto, es necesarios que abráis Google cloud Shell, o instaléis

5. En CLOUD Shell, utilizaremos el siguiente comando:

  • gcloud compute images import [IMAGE_NAME] --source-file [SOURCE_FILE] --os[OS]  


En la documentación oficial aparece separadas la variables con barras pero a mi me ha dado error y me ha funcionado la quitarlas. https://cloud.google.com/compute/docs/images/importing-virtual-disks

  • Ej: gcloud compute images import imagen1 --source-file gs://zrkvms/test1.vhd --os windows-2016


Este es el proceso que comentaba antes. Si no habéis habilitado el API que comentaba al principio del post, la primera vez que lancéis el comando, tras varios minutos os preguntará si queréis habilitar y si decís Yes, tras bastantes minutos fallará, teniendo que volver a lanzar el comando, tras dar tiempo a que se habilite la API.

6. Una vez tenéis ya creada la imagen, podéis crear de esta, tantas máquinas virtuales deseeis.

Ir a imagenes ligadas a vuestra suscripción:



7. Podeis crear una instancia eligiendo diferentes opciones para la misma.






Saludos.

jueves, 18 de abril de 2019

Azure–Mover recursos entre suscripciones

Hola,
A continuación os voy a detallar como mover todos los objetos de un mismo grupo de recursos entre suscripciones. A tener en cuenta que las suscripciones han de estar en el mismo Tenant.

Entorno gráfico:
Tenéis que ir a ver todos los items existentes en un grupo de recursos y allí pulsar en Subscription CHANGE.
Tenéis que elegir la suscripción de destino.


Tras esto, tenéis que pulsar en Move, opción que aparece en la parte superior y podréis elegir qué items queréis mover.



Una vez hecho esto, veréis como los items se han movido a la suscripción de destino.


Script:
El script que he desarrollado es el siguiente. Podéis variarlo para que no mueva todos los recursos, evidentemente.

Get-azurermsubscription
#ver suscripciones ID

Set-Azurermcontext -Subscriptionid #nos fija en la suscripción deseada.

Get-azurermresourcegroup
#ver nombre de grupos de recursos

RGDestion= "Nombre de RG de destino"
$Susdestino= "Nombre de suscripción de destino"
$Resources = (Get-AzureRmResource –ResourceGroupName “Name”)
#ver https://docs.microsoft.com/en-us/powershell/module/azurerm.resources/get-azurermresource?view=azurermps-6.13.0

foreach ($resource in $Resources) {
             Move-AzureRmResource -DestinationResourceGroupName $RGDestino -ResourceId $resource.ResourceId -DestinationSubscriptionId $Susdestino -Verbose
         }
 

Convertir disco VHDX a VHD previa subida a Azure y consideraciones

A continuación os detallo cosas a tener en cuenta sobre la conversión de VHDX a VHD, formato necesario para subir este disco a Azure. Además de la condición de subir discos VHD, contamos también con la condición de que el VHD sea de tamaño fijo.

Pero antes de pasar a detallar los pasos necesarios para la conversión, es conveniente que sepáis lo siguiente:

1. Un disco VHD puede tener un máximo de 2TB, no existiendo este límite en discos VHDX
2. Al punto anterior cabe destacar que Hyper-V permite lo que ningún otro sistema de virtualización; esto es, reducir el tamaño de los discos. Por todo ello, considero importante que dominéis variables y comandos como:
Convert-VHD   -VHDType Fixed
- Resize-VHD –SizeBytes XXXGB
- Resize-VHD –TominimumSize
IMPORTANTE: la tarea de Resize, solo se puede realizar sobre archivos VHDX, por lo que han de ser realizadas previa conversión a VHD.

Bien, para realizar la tarea de convetir VHDx a VHD, podemos utilizar Powershell o entorno gráfico, a continuación tenéis los pasos para ambos.

Powershell:
Convert-VHD –Path c:\origen\discovhdx.vhdx –DestinationPath c:\destino\destinoVHD.VHD –VHDType Fixed

Para que el resultante sea un disco de tamaño fijo. debéis añadir la variable –VHDType Fixed

Entorno gráfico:
Clic sobre Editar disco en consola de Hyper-V y continuar el asistente según capturas.







miércoles, 17 de abril de 2019

Azure - Crear una VM tras subir un VHD y recomendaciones

Hola,

A continuación os detallo el script necesarios para, usando Azure Powershell, crear una VM tras haber subido el disco VHD a un Container existente en un Blob Page.

Antes de detallaros el scipt, tener en cuenta lo siguiente:

- Si la máquina corre actualmente en un Hyper-V y tiene un disco VHDX, con la propia consola de Hyper-V y con la VM apagada, podéis editar el disco y partiendo de él, crear un archivo VHD Fijo.

- Crear VM en modo Generalized, se considera que el disco ha sido preparado para partiendo de él, crear varias máquinas virtuales. Por ello, a la VM modelo se le hace un sysprep antes de subir el VHD a Azure. (https://docs.microsoft.com/es-es/azure/virtual-machines/windows/capture-image-resource)

- El script es válido para una VM “Specialized”. Esto es una AzureVM creada a partir del VHD que es el mismo disco duro que estaba corriendo en una VM Hyper-V/Vmware en los que se ha convertido su disco VHDX o VMDK a VHD Fijo.

- Que tras crear la VM tenéis que instalar el agente de gestión de Azure, para el mero hecho de poder hacer Backups de la VM o bien por ejemplo utilizar opciones como resetear contraseña, monitorizarla, etc. (https://go.microsoft.com/fwlink/?LinkID=394789&clcid=0x409) A riesgo de ver errores como estos:

https://docs.microsoft.com/es-es/azure/backup/backup-azure-troubleshoot-vm-backup-fails-snapshot-timeout#the-agent-installed-in-the-vm-but-unresponsive-for-windows-vms

Script:

Este script cambia el orden y algunas pequeñas cosas, dando a mi juicio mayor sentido común, en relación a los pasos aparecidos aquí: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sa-create-vm-specialized

En el script partimos de tener un Grupo de recursos creado y el VHD subido.

$rgName = "RG1"
$location = "North Europe"
$vnetName = "Vnet1"
$vnet = New-AzVirtualNetwork -Name $vnetName -ResourceGroupName $rgName -Location $location -AddressPrefix     172.16.224.0/19 -Subnet $singleSubnet

$nsgName = "SG1"
$rdpRule = New-AzNetworkSecurityRuleConfig -Name myRdpRule -Description "Allow RDP" `
     -Access Allow -Protocol Tcp -Direction Inbound -Priority 110 `
     -SourceAddressPrefix Internet -SourcePortRange * `
     -DestinationAddressPrefix * -DestinationPortRange 3389
$nsg = New-AzNetworkSecurityGroup -ResourceGroupName $rgName -Location $location `
     -Name $nsgName -SecurityRules $rdpRule

$subnetName = "Vnet1_subnet1"
$singleSubnet = New-AzVirtualNetworkSubnetConfig -Name $subnetName -AddressPrefix 172.16.224.0/24

$ipName = "PUblicIP1"
$pip = New-AzPublicIpAddress -Name $ipName -ResourceGroupName $rgName -Location $location -AllocationMethod Static

$nicName = "VM1Nic1"
$nic = New-AzNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $location -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id

$vmName = "Vm1"
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize "Standard_A2"

$vm = Add-AzVMNetworkInterface -VM $vmConfig -Id $nic.Id

$osDiskUri = https://XXXXXXXX.blob.core.windows.net/xxxxx/XXXXXX.vhd

$osDiskName = $vmName + "osDisk"
$vm = Set-AzVMOSDisk -VM $vm -Name $osDiskName -VhdUri $osDiskUri -CreateOption attach –Windows


New-AzVM -ResourceGroupName $rgName -Location $location -VM $vm –DisableBginfoExtension –credential (get-credential)

*Atentos a DisableBGINfoExtension  : De no deshabilitar tendréis problemas por ejemplo a la hora de configurar los discos como gestionados.

*-Credential: Es importante proporcionar a Azure las credenciales de un usuario administrador de la máquina, Si esto se realiza, se puede evitar la variable –DisableBgInfoExtension.

martes, 9 de abril de 2019

Atributo de Exchange en Active Directory con O365

Hola,

Es muy probable que tengáis un escenario con O365 sincronizado con un AD clásico vía ADConnect en el que no haya estado nunca instalado Exchange.

En este escenario descrito, no encontraréis en los usuarios y grupos locales, ciertos atributos que si están en el objeto de Azure AD, pero que allí arriba, no podéis variar, dado que el objeto está sincronizado desde el AD Clásico.  Además, cambiar el valor de estos atributos, es necesarios para poder conseguir ciertas funcionalidades, como evitar que al usuario o grupo le llegue correo externo, desaparezca de la libreta global de direcciones, etc.

Solución

Pues bien, para poder tener a vuestro en vuestro AD local los atributos que estáis viendo desactivados en O365, tenéis que ampliar el esquema utilizando la instalación de Exchange Server 2016. Yo de hecho pienso que cabría hacerlo por defecto en toda instalación nueva de ADConnect.

1. Para realizar esto, tenéis que conseguir el DVD de instalación de Exchange. El cual anteriormente era público pero ahora, para disponer de él, tendréis que recurrir a una suscripción MSDN o similar.

2. Iniciar sesión con un administrador del dominio. Mi consejo es que si no tenéis a mano el administrador original del dominio, copieis este creando uno nuevo. Los usuarios que han sido itnroducidos en grupo Admin del dominio, Administador de esquema, etc. no suelen funcionar.

3. Una vez descomprimido su contenido en el disco del DC que es Administrador de esquema (netdom query fsmo es el comando que tenéis que lanzar para saber qué DC es el administrador de Esquema) y con el CMD como administrador abierto. tenéis que lanzar el siguiente comando:

- .\Setup.exe /PrepareSchema /IAcceptExchangeServerLicencesTerms




4. Actualizar el Schema en ADConnect


y con esto, tendremos los atributos necesarios en los usuarios: