Hyper-V: Conectar una maquina virtual a otro VMSwitch con PowerShell

Para conectar una máquina virtual a un VMSwitch distinto al que tiene asignada o asignarle uno por primera vez en caso de que no este conectada, se puede seguir el siguiente ejemplo. En primer lugar, verificar a que switch virtual está conectada la VM (si es que tiene alguno asignado):

PS C:\Users\Administrador> get-vm -Name vm1 | Get-VMNetworkAdapter

Name             IsManagementOs VMName SwitchName MacAddress   Status IPAddresses
----             -------------- ------ ---------- ----------   ------ -----------
Adaptador de red False          vm1               00155D581500 {Ok}   {}

En este caso se ve que el adaptador de esta VM no está conectado a ningún switch virtual. Como este servidor aún no tiene ningún VMSwitch, empiezo verificando las interfaces físicas disponibles en el equipo:

PS C:\Users\Administrador> Get-NetAdapter

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
Ethernet0                 Intel(R) 82574L Gigabit Network Conn...       4 Up           00-0C-29-F7-C4-22         1 Gbps
vEthernet (int_switch)    Hyper-V Virtual Ethernet Adapter             12 Up           00-15-5D-58-15-01        10 Gbps

En este servidor la interfaz física Ethernet0 está libre, con el siguiente comando creo un VMSwitch asociado a la misma:

PS C:\Users\Administrador> New-VMSwitch -Name vmswitch_prod -NetAdapterName "Ethernet0" -AllowManagementOS $true

Name          SwitchType NetAdapterInterfaceDescription
----          ---------- ------------------------------
vmswitch_prod External   Intel(R) 82574L Gigabit Network Connection

Finalmente, conectamos el adaptador de la máquina virtual al VMSwitch nuevo con el cmdlet Connect-VMNetworkAdapter y verificamos:

PS C:\Users\Administrador> get-vm -Name vm1 | Get-VMNetworkAdapter | Connect-VMNetworkAdapter -SwitchName vmswitch_prod
PS C:\Users\Administrador> get-vm -Name vm1 | Get-VMNetworkAdapter

Name             IsManagementOs VMName SwitchName    MacAddress   Status IPAddresses
----             -------------- ------ ----------    ----------   ------ -----------
Adaptador de red False          vm1    vmswitch_prod 00155D581500 {Ok}   {}

Leer mas

PowerShell: Determinar el historial de membresias de grupo en Active Directory

Hay ocasiones en donde es necesario conocer en que momento un usuario fué agregado a un grupo, en estos casos, esta información puede extraerse de Active Directory gracias a ciertos atributos existentes en los metadatos de replicación.

PS C:\Users\Administrador>
PS C:\Users\Administrador> $username = "juan"
PS C:\Users\Administrador> $userobj  = Get-ADUser $username
PS C:\Users\Administrador>
PS C:\Users\Administrador> Get-ADUser $userobj.DistinguishedName -Properties memberOf |
>>  Select-Object -ExpandProperty memberOf |
>>  ForEach-Object {
>>     Get-ADReplicationAttributeMetadata $_ -Server localhost -ShowAllLinkedValues |
>>       Where-Object {$_.AttributeName -eq 'member' -and
>>       $_.AttributeValue -eq $userobj.DistinguishedName} |
>>       Select-Object FirstOriginatingCreateTime, Object, AttributeValue
>>     } | Sort-Object FirstOriginatingCreateTime -Descending

FirstOriginatingCreateTime Object                                               AttributeValue
-------------------------- ------                                               --------------
6/7/2019 17:48:59          CN=Administradores clave,CN=Users,DC=seclab,DC=local CN=juan,CN=Users,DC=seclab,DC=local


PS C:\Users\Administrador> 

Como se ve en la salida del script anterior, con esto puede determinarse en que fecha un usuario fué agregado a uno o mas grupos. Podría ser que necesitamos esa información con fines forenses, o bien para determinar que membresias de grupo podrían ser reducidas en caso de que algún usuario experimente problemas de "token bloat". El script es una colaboración de Ashley McGlone, ex Premier Field Engineer de Microsoft, aquí puede verse el articulo original.

Por último vale mencionar que ademas de funcionar con cuentas de usuario, puede utilizarse con cuentas de equipos, sustituyendo Get-ADUser por Get-ADComputer

Leer mas

Solución al error de autenticación en conexión a Escritorio remoto "Oracle/CredSSP"

Las actualizaciones de Mayo del 2018 trajeron sorpresas para los administradores de entornos donde las conexiones RDP dejaron de funcionar repentinamente. Microsoft publicó un articulo donde detalla el alcance de la vulnerabilidad de CredSSP cuyos parches trajeron consigo este inconveniente que se presenta principalmente en los casos donde el cliente ya tiene las actualizaciones de 05/2018 y el servidor aún no cuenta con las mismas.

El error que se presenta al intentar conectarse desde un cliente actualizado a un servidor sin el parche es el siguiente:

An authentication error occurred. The function requested is not supported.This could be due to CredSSP encryption oracle remediation

Error de autenticacion. No se permite la funcion solicitada.Puede deberse a una actualizacion de Oracle de cifrado CredSSP

Desde luego la solución mas recomendable es aplicar la actualización en clientes y servidores que se manejaran vía RDP, pero en casos donde es imperioso acceder a un servidor que aún no esta parchado es posible cambiar el comportamiento del cliente para que ignore la vulnerabilidad utilizando políticas de grupo o directamente modificando el registro, el cambio requiere un reinicio para tomar efecto.

Via gpedit.msc:

Vía regedit:

PS C:\Users\Administrator> reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /f /v AllowEncryptionOracle /t REG_DWORD /d 2
The operation completed successfully.

PS C:\Users\Administrator>

Luego de parchear los servidores, lo recomendable es revertir el cambio para no dejar el sistema expuesto al robo de credenciales.

Leer mas

Paso a paso: Administración remota de Hyper-V en grupos de trabajo

Para administrar remotamente un servidor Hyper-V en casos donde la estación de trabajo o el servidor están en un grupo de trabajo, deben realizarse algunas configuraciones previas que detallo en esta entrada.

Configuración en el servidor Hyper-V

Habilitar la administración remota:

PS C:\Users\Administrator> Configure-SMRemoting.exe -Enable
Server Manager Remoting is now enabled: Enabled remote access.

PS C:\Users\Administrator>

Crear las reglas de firewall necesarias para la administración remota:

Set-NetFirewallRule -DisplayGroup 'Windows Management Instrumentation (WMI)' -Enabled true -PassThru
Set-NetFirewallRule -DisplayGroup 'Remote Event Log Management' -Enabled true -PassThru
Set-NetFirewallRule -DisplayGroup 'Remote Volume Management' -Enabled true -PassThru

Habilitar CredSSP en el servidor:

PS C:\Users\Administrator> Enable-WSManCredSSP -Role Server -Force

Configuración en el cliente

Habilitar el servicio winrm y añadir el host HYPER-V a los equipos de confianza del cliente:

PS C:\Windows\system32> winrm quickconfig
WinRM service is already running on this machine.

PS C:\Windows\system32> winrm set winrm/config/client '@{TrustedHosts="hyperv"}'
Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = true [Source="GPO"]
    Auth
        Basic = true
        Digest = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = true
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts = hyperv

PS C:\Windows\system32>

Al igual que en el servidor, en el cliente necesitamos una regla de firewall para permitir la administración remota de volúmenes:

Set-NetFirewallRule -DisplayGroup 'Remote Volume Management' -Enabled true -PassThru

Agregar el hostname y dirección IP del servidor al archivo C:\Windows\System32\Drivers\etc\hosts

Modificar la política de seguridad local (gpedit.msc) para permitir delegación de credenciales (agregar wsman/* en la lista de servidores para poder administrar cualquier servidor remoto):

Configurar las opciones de seguridad COM con la utilidad ubicada en C:\Windows\System32\dcomcnfg.exe, aquí debemos permitir el acceso remoto para anonymous logon:

Comprobamos la conectividad al servidor Hyper-V remoto, en este caso utilizando credenciales alternativas:

Leer mas

Virtualizacion anidada (nested virtualization) en Windows Server 2016

Una nueva característica de Hyper-V en Windows Server 2016 es la de virtualización anidada o nested virtualization, que nos permite ejecutar un hipervisor como ESX o KVM dentro de un guest de Hyper-V. Este feature muy útil para ambientes de laboratorio se habilita por máquina virtual con el  comando Set-VMProcessor sobre la VM apagada.

Para comprobar si la virtualización anidada ya esta habilitada en una VM utilizar Get-VMProcessor:

Como la mayoria de los features disponibles en Hyper-V corriendo sobre Windows Server 2016, la virtualización anidada también puede utilizarse en Windows 10 con Hyper-V. Esto requiere Windows 10 versión 1607 en adelante.

Leer mas

Node fairness: Controlando el Balanceo de maquinas virtuales en Hyper-V 2016

En Windows Server 2016, Microsoft introdujo una nueva característica de Failover Clustering disponible exclusivamente para el rol Hyper-V. Se trata de Node Fairness, una funcionalidad pensada para mantener balanceada la carga de los nodos del cluster redistribuyendo maquinas virtuales cuando detecta que algún nodo esta sobrecargado. Las maquinas virtuales se mueven a nodos con menor carga mediante migraciones en vivo y por lo tanto sin disrupción de servicios.

El feature viene activo por defecto y ya sea mediante Powershell o la consola de Failover Cluster Manager, puede desactivarse, configurar cuando entrará en acción y ajustar la agresividad de la heuristica que utiliza el cluster para determinar cuando un nodo esta sobrecargado.

AutoBalancerLevel

Hay 3 niveles de agresividad para esta heuristica:

AutoBalancerLevel	Agresividad	Porcentaje de carga del Host
1	Baja	80%
2	Media	70%
3	Alta	60%

Para visualizar el valor por defecto:

PS C:\Users\Administrador.CONTOSO> Get-Cluster -Name cluster01 | fl autobalancerlevel

AutoBalancerLevel : 1

Como puede verse, AutoBalancerLevel esta por defecto establecido en 1, un valor bastante relajado, que indica que si la CPU o memoria llegan al 80% de uso deberá empezar a hacer migraciones en vivo de maquinas virtuales a otros nodos del cluster.

Para ajusta el valor de AutoBalancerLevel con PowerShell:

PS C:\Users\Administrador.CONTOSO> (Get-Cluster).AutoBalancerLevel = 2

AutoBalancerMode

Otro valor configurable es AutoBalancerMode, que determina en que momentos se verificará la carga de trabajo de los nodos, por defecto viene establecido 2, lo cual hace uso de los nuevos nodos agregados al cluster para rebalancear la carga de VMs y también controla cada 30 minutos que ningún nodo este sobrecargado, de forma que si algún nodo del cluster falla y las maquinas virtuales migran a otros nodos, Node Fairness se encargará de corregir la distrubución de carga de VMs en los nodos sobrevivientes.

AutoBalancerMode	Comportamiento
0	Deshabilitado
1	Balancear solo al agregar nuevos nodos
2	Balancear al agregar nodos y cada 30 minutos

Para cambiar este valor con PowerShell:

PS C:\Users\Administrador.CONTOSO> (Get-Cluster).AutoBalancerMode = 1  

Para modificar estos valores desde la consola Failover Cluster Manager, en las propiedades del clúster, modificar las opciones de la pestaña equilibrador:

Salvo excepciones por necesidades específicas, la configuración por defecto es apropiada para la mayoría de los escenarios. Node Fairness respeta las políticas existentes de anti-affinity y possible owners configuradas en el cluster.

Balanceo de VMs en Virtual Machine Manager

En un clúster manejado por VMM, Node Fairness se desactiva automáticamente en favor del feature Dynamic Optimization presente desde Virtual Machine Manager 2012, cuya funcionalidad es equivalente e incluso va un poco mas allá, permitiendo configurar que el balanceo ocurra en schedules establecidos por el administrador.

Leer mas

Virtual Machine Manager: Error durante fase "specialize" al crear VM desde plantilla

Recientemente estuve realizando un deployment del controlador SDNv2 de Microsoft Network Controller en un ambiente de pruebas, para esto utilice la plantilla de servicio para VMM disponible en el Github de Microsoft. La tarea terminaba con un warning e inspeccionando la consola de las 3 máquinas virtuales en todas aparecía el siguiente error:

 
Luego de otros intentos fallidos tratando de determinar si se trataba de que el VHD de Windows Server 2016 estuviese dañado, me fijé en un detalle mas básico que omití modificar en el template de VMM, la zona horaria establecida en la plantilla era distinta a la del Domain Controller del lab, y para complicar aún mas el escenario, el servidor VMM también tenía otra zona horaria. Luego de corregido este detalle el deployment del servicio finalizó correctamente. Si bien este no era mi caso, otra causa de este error podría ser que la cuenta especificada en la plantilla para unir el equipo al dominio no cuente con privilegios para hacerlo.

En otros casos donde el origen del error no sea tan evidente, puede montarse el VHD de la VM problemática y revisarse la ruta %WINDIR%\Panther\ para investigar que datos arroja el log del sysprep.

Leer mas