Migración de GPOS entre dominios

Buenas,

En este post me gustaría explicar como migrar las configuraciones de una gpo entre distintos dominios teniendo en cuenta que la gpo origen tiene una serie de permisos personalizados los cuales convertiremos al dominio destino antes de hacer la migración.

En nuestro escenario de test tenemos una gpo origen con los siguiente permisos para la cual pretendemos sus parámetros a otro dominio y personalizar los permisos de la gpo de destino.

Una vez detallado el escenario pasamos a detallar los pasos que debemos realizar.

1- Abrimos la GPMC en el dominio origen – Pinchamos con el botón derecho sobre la gpo a migrar y hacemos un backup

2- Movemos el backup realizado a un controlador de dominio del dominio destino y abrimos la gpmc

3- En La GPMC pinchamos en group policy y posteiromente en Action – open migration table editor

4- A continuación pinchamos en tolos – populate from backup – seleccionamos nuestro archivo de copia de seguridad marcamos los dos check box y lo abrimos

5- Seleccionamos el grupo que queramos modificar y pinchamos en browse para reemplazarle por el que queramos del dominio destino

6- Pinchamos en File – save as y guardamos nuestro archivo de migración de tablas el cual contendrá la conversión de grupos

7- Creamos una gpo nueva con el nombre que queramos en el dominio destino – pinchamos con el derecho sobre ella y seleccionamos la opción restore from backup

8- En el asistente de restuaración elegimos la ruta donde se encuentra el archivo de backup que realizamos con anterioridad y el arhivo de conversión de tablas y seguimos los pasos para realizar la restauración

Esto sería todo, espero que os resulte de utilidad.

Un saludo

Azure Site Recovery (3 de 3 Configuración final y replicación de máquinas)

Buenas tardes

De acuerdo con lo prometido en esta tercera y última entrada de la serie veremos las opciones que debemos configurar en nuestra cloud de azure así como el procedimiento para habilitar la replicación de ciertas máquinas que tenemos corriendo nuestro SCVMM on-premises

Para configurar la protección de nuestra nube de SCVMM en azure seguiremos los siguientes pasos:

1- Nos logamos en el portal de Azure.

2- Pinchamos en Recovery services – nombre del vault – Set up protection for VMM clouds.

3- Pinchamos en configure protection settings y definimos las opciones de protección que en nuestro caso serán las siguientes:

4- El paso siguiente que realizaremos es la configuración del mapeo de redes entre nuestras redes on-premises y la redes de azure, para hacer esta configuración pinchamos en map networking mapping en el portal de azure y configureamos la opciones deaseadas.

Una vez realizado estos pasos veremos como aparece en azure la opción de habilitar la replicación para cualquier máquina compatible que se encuentre en la cloud que hemos marcado como replicada. En nuestro ejemplo hemos configurado la replicación para la nube test cloud en la que se encuentra la vm tst-replikazure.

Por lo tanto dentro de azure tenemos la opción de habilitar la replicación para esta maquina como podéis ver en el pantallazo adjunto.

Por último simplemente me gustaría adjuntaros el siguiente en el que se detallan los prerequisitos que deben cumplir la infraestructura y las máquinas replicadas.

http://msdn.microsoft.com/en-us/library/dn469078.aspx

Espero que resulte de utilidad.

Un saludo

Azure Site Recovery (2 de 3 configuración de SCVVM)

Buenas tardes

Como ya adelante en la primera entrada de la serie la cual podéis leer aqui, hoy veremos como instalar y configurar Microsoft Azrue site recovery provider en nuestro servidor de virtual machines manager y como desplegar los agentes de Microsoft azure recovery services en nuestros host con hyper-v.

Sin más dilaciones pasamos a detallar los pasos que debemos seguir para configurar azure site recovery provider en nuestro servidor de scvmm.

1- Descargamos Azure site recovery provider en nuestro servidor de system center virtual desde el portal de Windows azure y lanzamos el instalador

2- En la pantalla de bienvenida hacemos clikc en install

3- Una vez completada las instalación hacemos click en next para iniciar la configuración

4- Definimos los parámetros de configuración a internet en caso de usar un proxy y pulsamos en next

5- Seleccionamos el certificado que creamos en el post anterior y pulsamos en next

6- Espeficamos la clave del vault de Windows azure la cual también vimos como obtener en el post anterior y pulsamos en next

7- Definimos si queremos encriptar los datos de la replicación. En nuestro caso al ser un entorno de test no lo haremos y pulsamos en next

8- Definimos un nombre amistoso y registramos nuestros servidor de scvmm

9- Por ultimo pinchamos en close

Una vez configurado el azure site recovery provider en nuestro servidor de scvmm pasamos a detallar como instalar los agentes de azure recovery en los servidores de Hyper-V.

1- Descarmos el instalador del agente desde el portal de Windows azure y lanzamos el instalador en nuestros hosts

2- Lo primero que hace el instalador es comprobar si tenemos todos los prerequisitos y descargar los que nos falten

3- Lo siguiente y ultimo que debemos hacer es elegir los paths de instalación.

Siguiendo estos pasos ya tendríamos preparados nuestros host de hyper y nuestro servidor de SCVMM para replicar máquina con azure, en el siguiente y último post de la serie veremos como configurar la replicación.

Espero que os resulte de utilidad

Un saludo

Azure Site Recovery (1 de 3 configuración de azure)

Buenas Tardes

Tras unas merecidas vacaciones :-) rengancho hoy con este primer artículo de una serie de tres en el que explicaremos como configurar azure para habilitar el disaster recovery de nuestras máquinas de hyper-v en azure o lo que es lo mismo veremos cómo configurar azure replicar nuestras máquinas virtuales corriendo en nuestro hyper-v on-promises, igualmente veremos como generar un certificado que nos permita cifrar la replicación entre nuestro servidor de system center virtual machine manager y azure

Si aún no eres familiar con esta funcionalidad la cual fue anunciada en el pasado teched de EEUU me gustaría redigirte a la lectura del siguiente articulo que escribi hace algo más de un mes.

http://blogs.itpro.es/samuellt/2014/07/08/azure-site-recovery-disaster-recovery-to-azure/

Una vez hecha esta breve introducción pasamos a detallar paso a paso como crear el cerfiticado que nos permitirá cifrar la replicación y como instalarlo en nuestro servidor de system center virtual machine manager. En nuestro caso utilizaremos la utilidad makecert.exe que viene dentro del Windows SDK y que podemos descargar fácilmente desde la web de Microsoft. Igualmente es importante mencionar que también podríamos usar un certificado generado por una CA externa o interna

1- Copiamos la utilidad makecert en nuestro servidor de SCVMM
2- Abrimos un cmd como administrador y ejecutamos el siguiente comando para generar el certificado:
makecert.exe -r -pe -n CN=hypervazurereplik -ss my -sr localmachine -eku 1.3.6.1.5.5.7.3.2 -len 2048 -e 01/01/2016 hypervazurereplik.cer
3- Instalamos el certificado generado en nuestro servidor de SCVMM y nos guardamos una copia para posteriormente importarlo en el portal de azure.

Una vez disponemos del certificado pasamos a detallar paso a paso como habilitar nuestro Azure para recibir la replicas de nuestros hyper-v on promises

1 – Nos logamos en el portal azure
2 – Creamos un nuevo Vault para alojar la replicación para ellos vamos a Data services – recovery services – site recovery vault. Aquí pulsamos en Create new – quick créate y elegimos el nombre y el datacenter de azure en el que se alojara el vault.

3 – Accedemos al dashboard del vault que acabamos de crear y configuramos el recovery con la opción de replicación entre los hyper-v serves y Windows azure

4 – Pulsamos en Manage certificate y cargamos el certificado generado para cifrar las comunicaciones entre nuestro on-promises y azure.

5- Por último pinchamos en get vault key y nos copiamos la clave generada, esta clave la utilizaremos cuando configuremos nuestra replicación on promises.

En el próximo post de la serie veremos como instalar y configurar Microsoft Azure site recovery provider en nuestro servidor de virtual machine manager y como desplegar los agentes de Microsoft azure recovery services en nuestro host con hyper-v

Espero que os resulte de utilidad.

Un saludo

Configurar google chrome mediante gpos

Buenas tardes,

Hoy me gustaría explicaros como se puede configurar google Chrome mediante gpos. Aunque es cierto que se pueden personalizar algunos parámetros de Chrome usando configuraciones de internet explorer es mucho más profesional y nos ofrece mucho mas más granularidad la plantilla de configuración desarrollada por google.

Antes de empezar con la parte práctica es importante mencionar que los parámetros definidos en la propia plantilla de google prevalecen sobre los de internet explorer, si por ejemplo definimos una página de inicio para internet explorer y otra distinta para chorme usando la plantilla de Chrome. La página de inicio aplicada para Chrome prevalece en este navegador sobre la de internet explorer.

Una vez hecha esta introducción veremos de forma práctica los pasos a seguir.

1 – Descargamos la plantilla en fomato adm o admx que nos permitirá configurar las settings de Chrome desde el siguiente link.

https://support.google.com/chrome/a/answer/187202?hl=en

2- Copiamos y descomprimimos los archivos descargados en un controlador de dominio.

3- Accedemos a la gpmc y creamos una gpo o editamos cualquier de las existentes. Deplegemos computer configuration – policyes – pinchamos con el botón derecho sobre administratives templates y seleccionamos add or remove templates.

4. Seleccionamos el archivos con extensión adm dentro de los descargados

5. Una vez realizado este paso pinchamos en classic administratives y veremos que dentro de google se no han creado nuevas opciones que serán las que nos permitirán configurar chorme mediante gpos.

Espero que os resulte de utilidad

Un saludo

Optimización del failover a la hora de procesar un logon en Directorio Activo

Buenas tardes,

Hoy me gustaría hablaros de como optimizar el failover al procesar un logon en directorio activo ante una posible caída del controlador de dominio que da servicio para el sitio que el que nos encontramos.

Primero que todo me gustaría explicar como funciona la función DC locator la cual nos permite localizar el controlador de dominio para el sitio que nos encontramos. Los controladores de dominio registran un registro SRV en DNS cada vez que se inicia el servicio netlogon en un determinado controlador de dominio. En registro SRV es el que permite a los usuarios encontrar el controlador de dominio en su localización como parte del inicio de sesión. Sin embargo, si solo tenemos un controlador de dominio para ese sitio y no somos capaces de alcanzarle por estar caído cualquier otro motivo, el proceso de inicio de sesión intenta localizar un SRV y contactar con un Controlador de dominio de manera aleatoria, como podéis imaginaros esto puede ser especialmente problemático en empresas con un número elevado de controladores de dominio y de sitios en el que los usuarios pueden ser redirigos a un controlador de dominio muy alejado en la red.

Para dar solución a esta problemática podemos usar la funcionaliad try_next_closest_site la cual esta soportada en los equipos clientes desde Windows vista y se puede habilitar de manera fácil mediante gpos editando el siguiente parámetro.

El cual encontramos sobre la ruta Computer Configuration – administrative templates –system – net Logon – Dc Locator Dns Records.

Igualmente es importante mencionar que este parámetro se basa en la configuración de active directory sites and services para determinar cuál es el controlador de dominio más cercano. Por lo tanto en los sitios que repliquen solo con otro sitio no tendremos ningún problema a la hora de determinar el más cercano y lo configurar automáticamente, sin embargo si tenemos más de una replicación contra ese sitio tendremos que jugar con los costes de replicación dando prioridad a los que tienen un coste más bajo. Adjunto os dejo pantallazo de un link entre sitio para que podáis ver donde se encuentra la opción del costo la cual no se modifica muy habitualmente.

Por último comentaros que una vez aplicada esta configuración podremos probarla de manera fácil ejecutando el siguiente comando desde un equipo cliente.

Nltest /dsgetdc: FQDN domainname /writable /trynextclosestsite

Espero que os resulte de utilidad.

Un saludo

Azure Site Recovery (Disaster Recovery to Azure)

Buenas tardes,

Hoy me gustaría hablaros de Azure Site Recovery, esta funcionalidad que fue anunciada en el pasado Teched de Norte America y esta últimamente en boca de todos los que jugamos y nos pegamos en nuestro día a día con la virtualización.

En este post me gustaría simplemente explicaros que es Azure Site Recory en que se diferencia de Azure Site Recovery manager y dejaros algunos enlaces a los que considero los recursos más potentes si quieres aprender como funciona esta funcionalidad o montar un laboratorio de la misma.

Por lo tanto definimos Azure Site recovery como la funcionalidad que nos permite replicar máquinas virtuales entre nuestros host de hyper-v y Microsoft Azure. Esta replicación se realiza via System centrer virtual machine manger y requiere la instalación de agentes en los host de Hyper-v y el el servidor de SCVMM. Azure site recovery nos permite también levantar las maquinas replicadas bien para realizar un test o bien para ofrecer servicio directamente si hemos sufrido un problema en el datacenter donde habitualmente corren las máquinas.

La principal diferencia entre Azure site Recovery Manager y Azure site Recovery es que azure site recovery manager es simplemente un orquestador que nos permite gestionar la replicación entre dos datacenter de hyper-v, simplemente controla un proceso de replicación y recovery entre dos centros de datos de un cliente. Sin embargo, Azure site recovery convierte Microsoft azure en el datacenter de respaldo y gestiona la replicación entre el datacenter del cliente y Micorosoft Azure.

Si quereis profundizar más en este tema, me gustaría recomendaros los siguientes recursos que desde mi punto de vista es donde mejor se explica.

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B322

http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-azure/

Por último remarcar que esta funcionalidad se encuentra de momento en preview y de momento no es recomendable montarla en producción, yo por mi parte intentare moterme un lab en cuanto saque un rato.

Un saludo y espero que os resulte de utilidad

Migración replicacion de Sysvol desde FRS a DFSR

Buenas,

A raíz de que Microsoft anunciara en el pasado Teched de Norte America el final del soporte para el protocoló de replicación FRS junto con el fin de soporte de Windows 2003 server me gustaría comentaros el procedimiento para realizar la migración de la replicación del sysvol en nuestros controladores de dominio desde FRS a DFSR.

Antes de empezar a detallar el procedimiento de migración es de suma importancia revisar que nuestro dominio y nuestros controladores de dominio cumplen los requisitos de migración que serían los siguientes:

1- Asegurarnos que tenemos espacio libre en todos nuestros controladores de dominio para aojar una nueva copia de sysvol, puesto que durante el proceso replicaremos dicha carpeta

2- Asegurarnos de que el built-in administradores tiene permisos de “manage uditing and security log” en todos los domain controllers. La mejor manera de asegurarnos es revisar la default domain policy

3- Asegurar que la replicación esta funcionando correcamente en todos los controladores de dominio. Esta tarea la podemos hacer mediante línea de comandos usando repadmin o mediante interface gráfico usando la herramienta Active Directory replication status tool

4- Asegurarnos que la carpeta Sysvol esta compartida en todos los controladores de dominio. La manera más fácil de hacer es usando el siguiente comando de dcdiag:
Dcdiag /e /test:sysvolcheck /test:advertising

Una vez hechas estas comprobaciones pasamos a detallar el procedimiento de migración, el cual es bantante sencillo y debe ser realizado en el controlador de dominio que aloja el role de emulador PDC

1- Ejecutamos el comando Dfsrmig /setglobalstate1
En este punto lo que hacemos es crear un copia de sysvol adicional usando DFSR como protocolo replicación, sin embargo el dominio sigue funcionado y montando la carpeta sysvol que ya teníamos replicada por FRS. Es importante esperar a que estos cambios repliquen en todos los controladores de dominio antes de ejecutar el siguiente comando.

2- Ejecutamos el comando Dfsrmig /setglobalstate2
En este paso seguimos manteniendo ambas replicas de sysvol por FRS y DFSR. Sin embargo en este momento ya comenzamos a dar servicio y montamos la carpeta que se encuentra replicada por FRS. Al igual que en el punto anterior, es importante esperar a que se replique a todo el dominio para ejecutar el siguiente y último comando. Igualmente es importante mencionar que en este punto aún tenemos posibilidad de rollback.

3- Ejecutamos el comando Dfsrmig /setglobalstate3
En este momento dejamos de replicar por FRS y eliminamos la sysvol que tenemos replicada mediante este protocolo. Una vez ejecutado este comando ya no hay vuelta atrás ni posibilidad de rollback.

Espero que os resulte de interés.

Un saludo

Nic Teaming en una máquina virtual (guest Os) bajo Hyper-V

Buenas tardes

Hoy me gustaría contaros como configurar un teaming en una máquina virtual corriendo bajo Windows server 2012r2. Está claro que esta funcionalidad no tiene demasiado sentido si ya tienes configurado nic teaming en el host puesto que ya estas aportando faliover y balanceo de carga de red en el host.

Sin embargo esta funcionalidad si nos puede resultar especialmente útil en las siguientes situaciones.

– Cuando queremos ofrecer un ancho de banda superior a nuestra máquina virtual y un solo adaptador de red virtual no es suficiente.

– Cuando la máquina virtual esta corriendo en un host que tiene varias tarjetas físicas y estas no están configuradas en teaming. En este caso podemos configurar el teaming un nivel superior en máquinas que sean especialmente criticas.

– Cuando usamos máquinas con SR-IOV. SR-IOV es una funcionalidad que hace un bypass a todo la capa del hypervisor y transfiere el trafico de red directamente entre los adaptadores del host y la máquina virtual. Esta configuración puede ser necesario para máquinas con altos requerimientos de red y si además queremos dotarla de balanceo y alta disponibilidad podemos usar nic Teaming.

Una vez hecha esta pequeña introducción teórica pasamos a ver de manera practica como configuramos esta funcionalidad en un máquina virtual con server 2012 r2 corriendo en un Host sobre hyper-v server 2012 r2.

1- Añadimos al menos dos adaptadores virtuales a nuestra vm.

2- En las opciones avanzadas de ambos adaptadores habilitamos el check “enable this network adapter to be part of a team in guest operating system”

3- Ya dentro de la maquina virtual y con el sistema operativo iniciado configuramos el teaming de los adaptadores. La best practice de configuración del teaming es switch indendent mode con dynamic load distribution.

Espero que os resulte de utilidad.

Un saludo

Mostrar solamente impresoras de mi localización en el astintente de Active Directory

Buenas,

En entornos donde se publican muchas impresoras mediante active directory resulta especialmente comodo mostrar a los usuarios solo las impresoras disponibles para la localización en la que realizan la búsqueda puesto que normalmente no suele tener ningún sentido instalar impresoras que se encuentran geográficamente en localizaciones distintas.

Para ello el asistente de búsqueda de impresoras a partir de Windows 7 se basa en la configuración del sites en services para ofrecer a los usuarios las impresoras que se encuentran en la misma subnet que él.

Sin más dilaciones pasamos a ver de manera practica como configurar el sites and services y las impresoras de red con esta opción.

1- Abrimos las consola de sites and services y creamos el site, en nuestro caso Office1

2- Creamos una subnet y la relaciones con el sitio recientemente creado, en nuestro caso 192.168.1.0/24

3- Editamos las propiedades de la subnet recientemente creada y definimos la localización, Madrid en nuestro caso

4- Una vez definida la localización editamos las impresoras compartidas en nuestro servidor de impresión para apuntarla a la nueva localización definida

5- Una vez realizados estos pasos tan solo sería necesario habilitar la siguiente settings mediante gpos en las máquinas de nuestros usuarios.

Espero que resulte de utilidad.

Un saludo