Category Archives: Windows 2008 R2

CA Servicios Windows Windows 2008 R2

Migración de una Entidad Certificadora de Servidor. Parte I – Exportación (actualización del post).

06/06/2014 Published by: Roberto Tejero

Este par de Post son una revisión de los que ya puse hace un par de años pero revisados y actualizados. También me he animado a esta actualización la petición a través de Twitter de @komzVT el pasado 26 de mayo.

Muy pocas veces nos encontramos en la tesitura de tener que migrar una Entidad Certificadora (CA) de un servidor, ya sea porque es antiguo, con pocos recursos, con demasiados roles o con un Sistema Operativo obsoleto, a un nuevo servidor, mas moderno, con un sistema operativo actualizado.

El caso que vamos a ver hoy es la migración de una Entidad Certificadora (CA) de un servidor con sistema operativo Windows Server 2003 a otro, mas moderno, con un sistema operativo Windows Server 2008 R2.

Esta migración la vamos a dividir en dos partes, Exportación en origen (Parte I), e Importación en destino (Parte II).

Exportación de la CA.

Volvemos a utlizar como base de nuestra migración el artículo de la base de datos de conocimiento de Microsoft KB298138 . Seguiremos sus pautas al pie de la letra.

¿Qué necesitamos?:

Realizar un Backup de la CA.
Exportar la configuración del registro de nuestra CA.

Tenemos dos opciones o por consola gráfica o por línea de comando utilizando Certutil.exe

Consola Gráfica

Desde la consola de gestión de la CA, lanzamos una copia de seguridad de la misma:

Una vez nos aparece el Wizard, seleccionamos siguiente, y nos aparece una serie de opciones, donde seleccionaremos la exportación de la Clave Privada, la base de datos y los logs, así como pondremos la ruta donde vamos a realizar nuestra copia de seguridad:

Ponemos una password para securizar la copia de seguridad:

Hereramienta Certutil

Ejecutamos el siguiente comando para realizar el backup de la base de datos:

Certutil.exe -backupdb <ruta>

y el siguiente comando para realizar el backup de la clave privada de la CA, con su correspondiente password:

Certutil.exe -backupkey <ruta>

Para terminar realizamos una copia de seguridad de la configuración del registro de la CA que se encuentra ubicada en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration. Al igual que en el proceso anterior, podemos realizarlo desde una línea de comando o a través de la herramienta Regedit/Regedt32.

Regedit:

Donde, despues de seleccionar la ruta que queremos exportar, pulsaremos, Fichero, Exportar, y, por ejemplo, seleccionaremos la misma carpeta que hemos creado antes para hacer el backup, guardando el fichero .reg

Desde línea de Comando:

Ejecutaremos el siguiente comando para exportar la entrada de registro a nuestra ruta:

Por cierto, se me ha olvidado comentar que todo esto también se puede hacer a través de Powershell, pero eso lo dejo para otro dia.

Y ya está esta primera fase.

Buen fin de semana y el lunes continuaremos con mas.

Administración Powershell Windows 2008 Windows 2008 R2 Windows 2012 Windows 2012 R2

Crear una Tarea programada con PowerShell. Backup de GPOs de AD.

08/05/2014 Published by: Roberto Tejero

Hola,

Hablábamos hace muy poco sobre cómo realizar un backup de GPOs de Directorio Activo en caliente y dejamos pendiente el hacerlo mediante una tarea programada, por PowerShell (PS), por supuesto. Pues nada, al tajo.

Para empezar cargaremos, si no lo tenemos cargado por defecto, el módulo de Tareas Programadas y el de Group Policy:

Import-Module ScheduledTasks, GroupPolicy

Aqui teneis un listado de todos los cmdlets contenidos en el módulo:

Un pequeño detalles es que este módulo esta accesible para importarlo desde PS 3.0, así que si teneis una versión inferior os recomiendo o actualizarla o descargar los módulos desde Codeplex (Aqui).

Podríamos crear la tarea programada con el cmdlet New-ScheduledTask directamente, pero para una mayor claridad y que se pueda entender para los profanos la vamos a dividir en variables:

Vamos a definir las siguientes variables que están incluidas en cualquier tarea programada:

$A => Acción/es a realizar.- En nuestro caso es la ejecución de otro cmdlet de PS: «Backup-GPO -ALL -Path I:\GPOS_AD». Tiene la peculiaridad de que ejecutamos un cmdlet dentro de otro cmdlet, asi que hacemos referencia a la ejecución %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe. También podemos ejecutar un script de powershell con múltiples acciones.
$T => Trigger o desencadenante.- En nuestro caso será la fecha de ejecución, diariamente, semanalmente, dias de la semana, a la hora que consideremos oportuna, una sola vez, etc. Tenemos un sinfin de opciones:

$U => Credenciales de ejecución.- Podemos asingar unas credenciales determinadas para la ejecución de la tarea.
$S => Configuración adicional.- En esta variable se guardan los parámetros de configuración de la tarea programada. Por defecto son los siguientes y, como todo, se pueden cambiar:

D$ => Nueva Tarea. Metemos todos estos datos en una tarea nueva.
Registro.- Hay que registrar la tarea con un nombre obligatoriamente.

Este es el script:

$A=New-ScheduledTaskAction -Execute ‘%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe’ -Argument ‘Backup-GPO -All -Path Z:\GPOS_AD’
$T=New-ScheduledTaskTrigger -Daily -At 2:45pm
$U=New-ScheduledTaskPrincipal -UserId «$($env:USERDOMAIN)\$($env:USERNAME)» -LogonType ServiceAccount
$S=New-Scheduledtasksettingsset
$D=New-ScheduledTask -Action $A -Principal $U -Trigger $T -Settings $S
Register-ScheduledTask TasK007 -InputObject $D

Y el resultado:

Desde el Task Scheduller podemos ver la nueva tarea:

El resultado de dicha tarea es el backup de nuestras GPO’s:

Todo un éxito. Probad a sustituir el cmdlet por un script de Powershell. Que tengais una buena semana.

Lecturas recomendadas:

– Technet.

– Hey Scripting Guy.

– Codeplex – PowerShell.

– MCPMagazine.

– Petri.co.il.

Buen fin de semana.

Directorio Activo Tools Windows 2008 Windows 2008 R2 Windows 2012 Windows 2012 R2

Active Directory Replication Status Tool – Herramienta del Estatus de la Replicación de nuestro Directorio Activo.

02/05/2014 Published by: Roberto Tejero

Buenos dias,

Hace un par de años publiqué un post sobre esta herramienta «Active Directory Replication Status«, pues ahora han sacado la versión 1.1 que podemos descargar desde este enlace.

Adreplstatus00003

¿Que nos aporta?

Nos muestra los errores de replicación de Directorio Activo (AD) ocurridos en nuestros dominios o bosques.
Prioriza los errores que tienen que ser resueltos con el fin de evitar la creación de objetos persistentes en dominios o bosques de AD.
Nos proporciona ayuda para resolver los problemas de replicación mediante vinculos a la base de datos de conocimiento de Microsoft Technet.
Permite que la información de replicación pueda ser exportada a otros administradores o profesionales para ser analizada offline.

Todo ello desde un entorno gráfico muy sencillo y muy ágil.

Requerimientos:

Sistemas operativos soportados donde poder instalar esta herramienta:

Windows 7,
Windows 8,
Windows Server 2003,
Windows Server 2008,
Windows Server 2008 R2,
Windows Server 2012,
Windows Vista,
Windows Server 2012 R2

Controladores de Dominio a monitorizar:

Windows Server 2003,
Windows Server 2008,
Windows Server 2008 R2,
Windows Server 2012,
Windows Server 2012 R2

Otros requerimientos:

.NET Framework 4.0 (es posible que nos pida .NET Framework 3.5 si se instala sobre Windows Server 2008).
Tener una cuenta de dominio con privilegios.

Instalación.

Muy sencilla. Hacemos doble click en el instalador y …. ya está:

Funcionamiento.

Hacemos un chequeo inicial como ejemplo. Lanzamos la herramienta y esta es su apariencia:

Procedemos a realizar un descubrimiento inicial, pudiendo ser tanto de nuestro Forest como de los dominios dependientes. Lanzamos dicha acción desde los botones superiores de la consola:

Y, en nuestro caso, no existen ningún problema de replicación entre mis Controladores de Dominios (DC). Si os fijais, he sustituido el nombre de cada DC por un color y la replicación entre ellos es muy diferente, no todos replican contra todos:

En la parte de abajo nos indica de que color nos apareceran los posibles eventos de error. Si entramos DC por DC, podemos ver la situación de la replicación partición por partición, como podeis ver en mi caso desde un DC de Madrid hacia un DC de Bilbao:

Así como podemos ver los diferentes test que realiza (nos pocos ¿verdad?). Podemos dejar de visualizar aquellos que no nos interesen o consideremos que no son necesarios:

Muy util esta herramienta.Y, para terminar, podemos exportar toda esta información en formato XPS, CSV o para echarle un vistazo «offline».

Espero que os guste.

Buen fin de semana y mejor puente para aquellos que lo van a disfrutar.

Administración Backup Powershell Windows 2008 Windows 2008 R2 Windows 2012 Windows 2012 R2

Restauración de una GPO de un backup con Powershell.

30/04/2014 Published by: Roberto Tejero

Hola,

Una vez visto la semana pasada «Cómo hacer un backup de nuestras GPO de Directorio Activo a través de PowerShell (PS), vamos a ver cómo realizar una restauración de las mismas.

Recordar que podemos realizar una restauración total o granular de cualquier GPO así que vamos a ver ambas:

Restauración Total:

Es un caso bastante particular e improbable, ya que implica que, probablemente, hayamos perdido o se hayan corrompido todas nuestras GPOs. Ejecutaremos el siguiente cmdlet:

Restore-GPO -All -Path C:\Backup-GPO

Con el siguiente resultado:

Se restauran no solo las GPOs, también información de la creación de cada GPO, fecha de modificación, Versión de usuario y versión de Equipo, dominio, propietario, etc.

Restauración de una GPO:

Este es el caso mas habitual, queremos restaurar una GPO que, por error humano, se ha borrado, eliminado o corrompido. Ejecutaremos el siguiente cmdlet:

Restore-GPO -BackupId -Path C:\Backup-GPO

Con el siguiente resultado:

Y ¿de dónde sale el parámetro BackupId?, pues como vimos al realizar el backup, las políticas se guardan con su número identificativo o GUID, que es que utilizaremos para identificar cada GPO:

El viernes un poquito mas.

Administración Backup Powershell Windows 2008 Windows 2008 R2 Windows 2012 Windows 2012 R2

Copia de seguridad de tus GPOs de Directorio Activo con Powershell.

22/04/2014 Published by: Roberto Tejero

Buenos dias,

Después de casi una semana de vacaciones, retomamos nuestros quehaceres cotidianos. Hoy empezamos con algo sencillo y directo. ¿Cómo hacer copia de seguridad de nuestros Objetos de Política de Grupos (GPO) de Directorio Activo utilizando Powershell.

Comentar que a partir de Windows Server 2008 R2, o sea, Powershell v2, se dispone de cmdlets específicos para la gestión de GPO’s de Directorio Activo. Primero tendremos que cargar el módulo «GroupPolicy», si no lo tenemos cargado por defecto. Podemos ver todos los cmdlets relacioandos con las GPOs:

Vamos a realizar nuestro primer Backup:

Backup-GPO -All -Path I:\GPOS_AD

I:\GPOS_AD es la ruta donde vamos a ubicar nuestro backup. y, para este ejemplo, hemos hecho un backup completo de todas las GPOs de nuestro dominio.

Por cierto, si os habeis fijado, en la primera captura he realizado un Get-Host para ver que versión de PowerShell tenía, la mas baja para nuestras intenciones, v2. Pues podemos ver qué módulos podemos importar, por defecto, a través del siguiente cmdlet:

Son muy pocas, Active Directory, ADRMS, AppLocker, BestPracties, ……… y GroupPolicy, por supuesto.

Para terminar este «Post Express«, como Buena Práctica que espero sigais, tendremos que programar un Backup ya sea por el entorno gráfico (GUI) como por Powershell pero esto, lo dejamos para otro Post. Yo ya lo tengo preparado:

Para rizar el rizo os dejo estas lecturas recomendadas con opciones mejoradas:

Script básico de realizar Backup de todas las GPOs con formato de fecha deseado.
Backup de todas las GPOs que han sido modificadas el último mes.
Blog Powershell.

Que tengais buena semana, yo empiezo hoy 😉

Cluster DFS esxi Proyectos Vmware vsphere Windows 2008 R2

Cómo crear un cluster Windows Server 2008 R2 sobre Hipervisor vSphere 5. Instalación del Rol Servidor de Ficheros.

24/02/2014 Published by: Roberto Tejero

Seguimos con nuestro proyecto de Servidor de Ficheros en cluster Windows Server 2008 R2 sobre vSphere 5 (ver este post antiguo y este otro). Por cierto, encontré un «checklist» de cómo montar un Servidor de Ficheros Clusterizado con Windows Server 2008 R2 que os adjunto:

	Step	Reference
	On every server that will be in the cluster, open Server Manager, click Add roles and then use the Add Roles Wizard to add the File Services role and any role services that are needed.	Help in Server Manager
	Review hardware and infrastructure requirements for a failover cluster.	Understanding Requirements for Failover Clusters
	Install the Failover Clustering feature on every server that will be in the cluster.	Install the Failover Clustering Feature
	Connect the networks and storage that the cluster will use.	Prepare Hardware Before Validating a Failover Cluster
	Run the Validate a Configuration Wizard on all the servers that you want to cluster, to confirm that the hardware and hardware settings of the servers, network, and storage are compatible with failover clustering. If necessary, adjust hardware or hardware settings and rerun the wizard until all tests pass (required for support).	Validate a New or Existing Failover Cluster
	Create the failover cluster.	Create a New Failover Cluster
	If the clustered servers are connected to a network that is not to be used for network communication in the cluster (for example, a network intended only for iSCSI or only for backup), then configure that network so that it does not allow cluster communication.	Modify Network Settings for a Failover Cluster
	Run the High-Availability Wizard and specify the File Server role, a name for the clustered file server, and IP address information that is not automatically supplied by your DHCP settings. Also specify the storage volume or volumes.	Configure a Service or Application for High Availability
	Add shared folders to the clustered file server as needed.	Create a Shared Folder in a Clustered File Server
	Test the failover of the clustered file server.	Test the Failover of a Clustered Service or Application

Una vez están configurados todos los nodos, hoynos toca crear el servidor de ficheros clusterizado.

Instalación del Rol en los nodos.

Este paso lo podemos realizar antes o despues de instalar la característica «Failover Cluster» en ambos nodos. Si os fijais en el Checklist lo incluye antes de instalar Failover Cluster. Pero bueno, yo lo hago ahora. Añadimos el Rol de File Server:

Incluimos el subrol del Gestor de Recursos de un Servidor de Ficheros:

Nos pide el disco que vamos a monitorizar y los informes que va a generar nuestro Gestor de Recursos:

Posteriormente nos solicita la carpeta donde se van a guardar dichos informes y si queremos que se envien por correo, a quién y a través de que servidor SMTP:

Para terminar, nos hace un breve resumen y lanza la instalación del Rol:

Este proceso lo haremos en todos los nodos del cluster. Os recuerdo que es mejor hacerlo antes de instalar la caractéristica de Failover Cluster. Y ya sabeis que todo, absolutamente todo se puede hacer con PS, así que aqui os dejo unas capturas rápidas de cómo se hace lo mismo:

Best Practices Analyzer (BPA).

Como ya sabemos, y si no lo sabíamos, ahora si, este rol tiene su Best Practices Analyzer (BPA), que nos hará recomendaciones sobre como optimizar nuestra infraestructura de Servidor de Ficheros. Lo ejecutamos:

Y en nuestro ejemplo nos aparecen un par de Warnings:

El primero los sulucionamos con este KB ff633453:

Lo solucionamos cambiando un valor del registro, a través de PowerShell:

Y el segundo con este otro KB ff633467:

Lo resolvemos borrando una entrada de registro:

Creación del Servicio Clusterizado de Servidor de Ficheros.

Ya estamos a punto de terminar. Asi que desde la consola de gestión de Failover Cluster, dentro de la carpeta de Servicios y aplicaciones configuraremos un nuevo Servicio:

Seleccionaremos el servicio de «File Server»:

Configuraremos el punto de acceso del cliente con su dirección IP

Y para finalizar configuraremos el disco que vamos a utilizar (Datos):

Finalizamos y nos da la opción de ver el informe que se ha generado:

Puede ocurrirnos que nos de el siguiente evento de error y nos acojonemos un poco, impidiéndo que cremos este servicio clusterizado:

Pero como casi siempre, lo podemos solucionar. Por ejemplo de estas dos maneras:

Por delegación de permisos.- Delegar el permiso de crear objetos de tipo «Computer» sobre la Unidad Organizativa donde se encuentren los componentes del cluster a través del Wizard de Directorio Activo.
Dar permisos antes de crear el Servicio Clusterizado.- Es lo mismo pero manual. Nos vamos a la OU donde se encuentran ubicados los nodos del cluster y damos permisos de crear objetos de tipo «computer» al Servidor Virtual del Cluster que hemos creado.

Y ya tendremos nuestro Servidor de Ficheros Clusterizado en Windows Server 2008 R2 sobre hipervisor Vmware vSphere 5.0. Mañana creamos un recurso compartido rapidito y terminamos este «mini-proyecto». Que tengais buena semana.

Bibliografía:

– Waclaw Chrabaszcz

– Technet LATAM.

Cluster DFS esxi Proyectos Servicios Windows Vmware vsphere Windows 2008 R2

Cómo crear un cluster Windows Server 2008 R2 sobre Hipervisor vSphere 5. Creación del Failover Cluster.

17/02/2014 Published by: Roberto Tejero

Continuando con la creación del cluster Windows Server 2008 R2 sobre vSphere 5 (ver este post antiguo). Una vez están configurados todos los nods, hoy toca crear dicho cluster. Ya vimos en otra serie posts como crear un Failover Cluster para Hyper-V y Windows Server 2012, asi que esto es mas de lo mismo (ver este post y este segundo post), y, para hacerlo nuevo y distinto, todo será a través de Powershell.

1 Configuración inicial:

Ya lo vimos en el post anterior pero en ella detallamos los siguientes puntos:

Configuración de los servidores. Instalación de sistema operativo y hotfixes.
Configuración de las redes (privada y pública) y la prioridad de las mismas (publica sobre privada).
Configuración de los discos (Quorum y Datos) a través de nuestro Hipervisor ESXi, ya sean iSCSI o FC (en modo RAW).
Presentación de los discos.

2 Instalación de requisitos.

Instalar Feature Failover Cluster en todos los nodos del cluster. Importaremos el módulo de Server Manager para poder añadir la característica de Failover Clustering.

Posteriormente, añadirermos el módulo de Failover-clustering para crear nuestro Cluster y empezar a gestionar recursos:

3 Validación de configuración.

Al igual que en modo gráfico podemos validar si todos y cada uno de nuestros nodos son válidos para la creación de un Failover Cluster. En nuestro caso tendremos el servidor naranja (servidor_g) y el servidor verde (servidor_h).

Ejecutamos el cmdlet Test-Cluster -node <nodo1>, <nodo2>

Nos aparecerá el resultado, en mi caso, con ciertos warnings y la ubicación del fichero con el informe:

Que, por defecto, nos lo ubicará en c:windowsClusterReports :

En este informe, como muy buen ejemplo, nos indica que uno de los dos nodos, concretamente el nodo verde, tiene dos hotfixes menos que el nodo naranja.

Si hacemos un Windows Update nos aparece lo siguiente:

Se instalan y volvemos a pasar el test con resultado óptimo.

4 Creación del Failover Clustering.

Procedemos a crear el Failover Clustering ejecutando el cmdlet New-cluster -name <Nombre> -Node <nodo1>,<nodo2> -StaticAddress <Dirección IP del Cluster>

Una vez creado, obtenemos la información de nuestro Failover-clustering (datos que podremos modificar para tunnear nuestra configuración mas adelante):

Al crear el Failover-Cluster, todos aquellos recursos como puedan ser NICs y Discos que tengan los nodos se incluyen en él. Estos son los recursos del nuestro Cluster:

Si nos fijamos, en el proceso de creación a los discos que ha encontrado y añadido al Cluster los ha nombrado Cluster Disk 1 y Cluster Disk 2. Procedemos a renombrarlos a nuestro gusto:

$NewName = Get-ClusterResource ‘Cluster Disk 1’;$NewName.name = ‘Quorum’

Lo podemos ver desde la consola gráfica cómo queda:

Lo mismo ocurre con las tarjetas de red, las renombramos nuevamente como deseemos, aunque se complica un poquito.

({Get-ClusterNetwork | Where-Object {$_.name -eq ‘Cluster Network 1′}}.name =’Public’

Y, para finalizar, nuestro sistema de Quorum o definición de mayoría de votos. Ejecutamos el cmdlet Get-ClusterQuourm | fl * donde nos dirá qué tipo de mayoría tenemos:

Si no es la que queremos, como es el caso ya que ha cogido como disco de Quorum el disco que hemos denominado «Datos», pues lo cambiamos: Set-ClusterQuorum -NodeAndDiskMajority ‘Quorum’

Pues hasta aqui la configuración básica.

5 Validación de la instalación.

Para finalizar procedemos a verificar y validar nuestra configuración de Cluster:

Pues todo fantástico. Que tengais muy buena semana.

Bibliografía:

Pablo A. Ahumada. Me ha parecido un post muy completo.

Technet. Comandos de Powershell para Failover Clusters.

Technet. Configuración de Servicios Clusterizados con Powershell.

Technet. Comandos mapeados de Cluster.exe a Powershell.

Directorio Activo Seguridad Servicios Windows Windows 2008 Windows 2008 R2 Windows 2012 Windows 2012 R2 Windows 7 Windows 8 Windows 8.1

Restringir el tráfico RPC de los Controladores de Dominio a un puerto o puertos determinados.

11/02/2014 Published by: Roberto Tejero

Como sabreis, gran parte de la comunicación entre Controladores de Dominio (DC), se realiza a través de RPC (técnica para la comunicación entre procesos en una o más computadoras conectadas a una red). Este tráfico RPC puede ser motivado por distintos servicios que se ejecuten en nuestros DC, como pueden ser:

DHCP.
Replicación de Directorio Activo.
Replicación FRS.
WINS.
Promoción de un Controlador de Dominio,
etc.

¿Cómo funciona RPC?

Para empezar una comunicación RPC, el cliente se conecta al puerto TCP 135 del servidor y solicita un puerto al End Point Mapper (EPM). El EPM del servidor reserva un puerto, denominado puerto dinámico, para este cliente y se lo envía. A partir de este punto, el cliente abre una nueva conexión TCP a dicho puerto del servidor y comienza la comunicación. Aqui os dejo un gráfico sobre un proceso Cliente/Servidor de RPC:

Estos puertos dinámicos RPC, también conocidos como puertos efímeros se distribuyen de la siguiente manera, dependiendo del sistema operativo:

Hasta Windows 2003/XP (del 1025 al 5000) = 3976 puertos en total.
Desde Windows 2008/Vista (del 49152 al 65535) = 16.384 puertos en total.

Hasta aqui todo correcto, pero ¿qué ocurre en zonas desmilitarizadas o DMZ dónde tenemos restringidos determinado tráfico y puertos?

Los puertos que generalmente utilizan los Controladores de Dominio en los servicios básicos son los siguientes:

Service	Port/protocol
RPC endpoint mapper	135/tcp, 135/udp
Network basic input/output system (NetBIOS) name service	137/tcp, 137/udp
NetBIOS datagram service	138/udp
NetBIOS session service	139/tcp
RPC dynamic assignment	Win 2k/2003:1024-65535/tcp Win 2008+:49152-65535/tcp
Server message block (SMB) over IP (Microsoft-DS)	445/tcp, 445/udp
Lightweight Directory Access Protocol (LDAP)	389/tcp
LDAP ping	389/udp
LDAP over SSL	636/tcp
Global catalog LDAP	3268/tcp
Global catalog LDAP over SSL	3269/tcp
Kerberos	88/tcp, 88/udp
Domain Name Service (DNS)	53/tcp1, 53/udp

Asi que nuestros Firewalls tendrán que tener abierto estos puertos para la comunicación entre DCs y clientes pero ¿qué ocurre con el tráfico RPC si hemos dicho que es dinámico? El hecho de tener que abrir un rango tan grande de puertos en el Firewall implica aumentar el riesgo de ataque ya que son 16384 puertos los que se exponen. Posible solución: restringir dicho tráfico a un número fijo de puerto o puertos.

Nosotros, por ejemplo, lo que queremos es forzar el tráfico RPC entre los puertos 5000-5100. Recordar, que es necesario y como mínimo, dejar un rango de 100 puertos consecutivos para un mejor funcionamiento y evitar cuellos de botella.

Tenemos tres métodos de realizarlo, dependerá de los servicios que queramos restringir:

Método 1 – Entradas en el registro sobre la configuración de los servicios de replicación de Directorio Activo.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters y añadimos la clave DWORD TCP/IP Port con el valor del puerto que queremos utilizar (incluyendo los espacios en blanco).

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters y añadimos la clave DWORD DCTcpipPort con el valor del puerto que queremos utilizar (incluyendo los espacios en blanco).

Método 2 – Para configurar en el Servicio Firewall de Windows el rango de puertos (para Windows 2008/Vista en adelante):

netsh int ipv4 set dynamicport tcp start=5000 num=1000
netsh int ipv4 set dynamicport udp start=5000 num=1000
netsh int ipv6 set dynamicport tcp start=5000 num=1000
netsh int ipv6 set dynamicport udp start=5000 num=1000

Y para verificar que está configurado:

netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport tcp
netsh int ipv6 show dynamicport udp

Método 3 – Para los servicios de comunicaciones de Windows. También afecta a las comunicaciones de Directorio Activo. Volvemos a trabajar en el Registro:

HKEY_LOCAL_MACHINESoftwareMicrosoftRpc

REG_MULTI_SZ: 5000-5100
PortsInternetAvailable: REG_SZ: Y
UseInternetPorts: REG_SZ: Y

Espero que os sea util. En un próximo post utilizaremos la herramienta «PortQuery» para verificar el tráfico RPC entre controladores de dominio.

Bibliografia:

Cluster DFS esxi Hyper-V Proyectos Servicios Windows Vmware vsphere Windows 2008 R2

Cómo crear un cluster Windows Server 2008 R2 sobre Hipervisor vSphere 5. Creación y preparación de Servidores.

07/02/2014 Published by: Roberto Tejero

Uno de mis últimos proyectos es montar un nuevo servicio de Servidor de Ficheros en la empresa en la que estoy trabajando. He tratado de mil formas de montarlo con Windows Server 2012 R2 pero al final vamos a montarlo con Windows 2008 R2. Os dejo algunas de las muchas ventajas que tiene uno sobre el otro:

SMB 3.0.
Dynamic Access Control (DAC)
Deduplicación.
Storage Spaces
PowerShell 3.0
Server Manager.
Mejoras en DFS Namespaces y DFS replication.

Por otro lado, antes de montar este clúster conviene leerse la documentación oficial y algún que otro blog de Vmware, Hyper-V, RHEL o XenServer para crear un Failover Cluster de Microsoft sobre plataformas de virtualización. Os dejo este link con el documento de vmware vSphere 5.

Este sería un gráfico típico de un Cluster entre dos servidores virtuales situados en distintos hosts de virtualización:

En este ejemplo, he creado en nuestra plataforma de virtualización de Vmware Vsphere 5.5 los 2 servidores con las siguientes características:

FILESHAREA.rob.com

DATASTORE: 69 HITACHI AMS2300
Nodo del Cluster: ESXIPO.rob.com
Disco C: 40 GB
4 GB de memoria RAM
4 vCPU
NIC’S:
- NIC 0: PUBLIC IP: por ejemplo 10.11.0.117
- NIC 1: PRIVATE IP: por ejemplo 192.168.0.1
Instalación de parches de seguridad hasta el día de la fecha.

FILESHAREB.bme.com

DATASTORE: 17 HITACHI AMS2300
Nodo del Cluster: ESXIPM.rob.com
Disco C: 40 GB
4 GB de memoria RAM
4 vCPU
NIC’S:
- NIC 0: PUBLIC IP: por ejemplo 10.11.0..118
- NIC 1: PRIVATE IP: por ejemplo 192.168.0.2
Instalación de parches de seguridad hasta el día de la fecha.

Instalamos los 2 servidores Virtuales con Windows Server 2008 R2 Enterprise o Datacenter de una forma limpia. Lo ideal es tirar de alguna plantilla ya creada pero para los menos organizados hacemos una instalación nueva. Podemos crearlos en cualquiera de las dos versiones, o ServerCore, mucho mas limpia y sin sobrecarga de la interface gráfica (GUI), o con la versión con GUI. Dependerá de nuestras necesidades y de nuestros recursos.

Como habeis podido observar, dispongo de una cabina de discos HITACHI AMS2300, donde mostraremos a nuestros Host de virtualización las siguientes LUNs:

Quorum.- Suele ser de unos 500 MB, mínimo.
Datos.- Vamos a mostrar una de 500 GB.

Entramos en la configuración de cada servidor de ficheros y añadimos un nuevo disco:

Indicamos que va a ser un disco en modo RAW:

Nos aparecerán las LUNs que desde Almacenamiento nos han mostrado, la de 500 MB y la de 500 GB:

Seleccionamos que queremos realizar el mapeo de la LUN en un disco VMDK y que se aloje en el mismo DataStore donde reside el Servidor:

Posteriormente, seleccionamos el modo de compatibilidad, en nuestro caso como lo vamos a tratar como si fuese un servidor físico con su controladora, seleccionaremos «Fisico»:

Y, para terminar, seleccionaremos el drive SCSI que no deberá estar utilizado por Vmware. En nuestro caso hemos utilizado las SCSI (1:0 y 1:1). Posteriormente, en la configuración del resto de nodos necesitaremos esta información:

Apuntaremos (Siguiendo recomendaciones de Vmware para no utilizar el puerto SCSI 0) :

SCSI 1:0 Para el disco de Quorum.
SCSI 1:1 Para el disco de Datos.

Una vez realizada esta selección nos aparecerá la pantalla de resumen y …. ya tendremos mapeadas las LUNs al servidor. Podremos ver que nos han aparecido tanto el nuevo disco como un nuevo controlador SCSI y, al ser Windows Server 2008 R2, es LSI Logic SAS:

Y, ojo, con la política de compartir discos virtuales ya que, normalmente, se queda en «none» y, como comprendereis, para nuestro ejemplo tiene que estar en «Physical»:

Todo esto habrá que hacerlo para todos y cada uno de los servidores que vamos a incluir en nuestro Cluster. Una vez dentro de la configuración del siguiente nodo del cluster en la consola del Virtual Center, procederemos a añadir el nuevo hardware y en todos estos nuevos nodos, seleccionaremos la siguiente opción para el tipo de disco:

Seleccionaremos uno por uno cada discos que se han «mapeado», que en nuestro caso los ha renombrado a FILESHAREA.ROB.com_1.vmdk y FILESHAREA.ROB.com_2.vmdk:

Volvemos a seleccionar los nodos SCSI virtuales:

Y nos aparecerá la ventana de resumen. Continuaremos seleccionado cada uno de los discos, que estarán en el Datastore en donde esté alojado el servidor que previamente hemos configurado así como el controlador SCSI que pertenece a cada uno de los discos que hemos añadido al mapeo de LUN. Comprobamos que la configuración SCSI está indicada en Physical.

Una vez terminado, podemos visualizar en ambos nodos del cluster que aparecen los discos para la creación del Cluster:

Para terminar, tenemos que recordar que hay que crear una regla de «Anti-Afinidad» para que no estén los dos nodos del cluster en el mismo Host de virtualización. Desde nuestro Virtual Center, nos situamos sobre el Cluster de Hosts de virtualización, botón derecho y «Editar propiedades».

Seleccionamos la regla y creamos una que vamos a denominar «Anti-Afinidad nodos del Cluster de ficheros», para que no estén ambos nodos del Cluster en el mismo host de virtualización. En el tipo seleccionaremos en nuestro caso «Separar Máquinas Virtuales» y seleccionaremos nuestros servidores:

Normalmente estas reglas tienen que funcionar pero si queremos asegurarnos del estricto cumplimiento de las reglas de afinidad, tenemos que seguir el siguiente procedimiento:

En opciones avanzadas de la configuración del servicio DRS de nuestro Cluster de Hosts de virtualización incluiremos una clave denominada ForceAffinePoweron con el valor de 1.

Ya tenemos preparado nuestros servidores con Windows Server 2008 R2 dispuesto a crear la semana que viene el Cluster de Ficheros con servicio DFS.

Buen fin de semana, jejeje.

Bibliografia:

Blog de eManu.