Redirigir equipos incluidos en dominio a 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.

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.

Atributos 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: