Category Archives: Servicios Windows

Administración Azure Rendimiento Servicios Windows Tools

System Center Advisor. Monitorización de nuestros servidores desde la nube.

05/08/2014 Published by: Roberto Tejero

Buenas tardes,

Hoy os comento esta otra herramienta que Microsoft pone a nuestra disposición de una manera gratuita, System Center Advisor (SCA) para utilizarla como herramienta de análisis del estado de salud de nuestra infraestructura de servidores Microsoft Windows.

Realmente es como un mini SCOM, producto de la familia System Center destinado, principalmente, a la Monitorización y generación de alertas, aunque hay que decir que solo nos guarda los datos recolectados de los últimos 5 dias, recordar que es Free.

¿Que nos proporciona esta herramienta que no tengamos ya?

Comprobación del estado de salud.
Cumplimiento de las mejores prácticas en equipos tales como:
- Windows Server 2012
- Windows Server 2008 (Datacenter, Enterprise y Standard).
- Windows Server 2008 R2 (Datacenter, Datacenter, Enterprise y Standard con o sin Hyper-V).
- Hyper-V Server 2012
- Hyper-V Server 2008 R2
- SQL Server 2008 y posteriores.
- Microsoft Sharepoint Server 2010
- Microsoft Exchange Server 2010
- Microsoft Lync Server 2010 y 2013.
- System Center 2012 SP1 – Virtual Machine Manager
Compatibilidad 100% con Azure.

Tendremos que instalar un agente monitor y otro agente gateway en nuestra infraestructura de servidores para que reporten directamente a la plataforma Azure.

Comentar que existen dos versiones de este producto, la gratuita, que es la que os voy a comentar y la que reporta directamente a SCOM. Aqui os dejo las principales diferencias entre ambas versiones:

ALTA EN EL SERVICIO.

Primero tendremos que darnos de alta en el servicio con una cuenta Microsoft Account, ya sabeis @outlook.com, live.com, Office365, etc. En el caso de no tenerla nos pedirá un nombre de cuenta, nuestro nombre y dirección de correo. Una vez aceptadas las condiciones empezaremos a realizar el despliegue.

sca000002

DESPLIEGUE.

SCA nos ayudará desde el principio con un asistente que nos irá guiando sobre qué tenemos que descargar e instalar en cada momento. En la primera imagen nos muestra un gráfico de cómo será el despliegue de la herramienta:

El primer paso será la instalación del agente que hará de Gateway o pasarella entre nuestra infraestructura de servidores y Azure. Procederemos a descargarnos tanto el software como el certificado que utilizaremos para cifrar las comunicaciones:

El segundo paso es la instalación del agente, propiamente dicho, de SCA, que, como ya nos daremos cuenta, es el mismo agente/servicio que se utiliza en SCOM:

INSTALACION DE AGENTES.

Los requisitos necesarios para la instalación de ambos agentes son .Net Framework 3.5, así que la mayoría de nuestros servidores lo cumpliran. Lanzamos el ejecutable y nos aparece la ventana de bienvenida:

Aceptaremos los términos de la licencia:

Definiremos una ruta donde instalar el producto o dejaremos la ruta por defecto:

Llegados a este punto, dependiendo del rol que vaya a tener cada servidor instalaremos el agente «Gateway» y el Agente de SCA.

Recordar que este servidor tiene que tener acceso a Internet, aunque supongo que eso ya lo tenías claro.

Siguiente, ….

Listos para empezar a instalar:

Instalando, que es gerundio …

Finaliza la instalación del producto:

sca000019

CONFIGURACION INICIAL

En los siguientes pasos, tendremos que instalar el certificado para cifrar las comunicaciones y verificar que la comunicación entre el Portal en Azure de SCA y nuestro Gateway es correcto, así como entre nuestro Gateway y nuestros Servidores.

Agente Gateway y Agente SCA

Desde nuestro servidor Gateway, se lanzará un asistente donde, inicialmente, definiremos cómo accedemos a Internet así como cargaremos el certificado:

Nos informará si queremos instalar las últimas actualizaciones a nuestro servidor , por defecto nos pone que si:

Nos confirmará los pasos a seguir:

Nos va mostrando todos y cada uno de los chequeos que realiza y …. todo correcto, hay conexión con Azure:

Como hemos dicho que si haga un Windows Update … pues se pone a ello

Y ya nos aparecen datos en nuestra consola, aunque solo son de la conexión pero podemos ver ya ambos agentes conectados. Recordar que habrá que esperar 24 horas para que empiece el reporte de toda la información:

sca000027

Agente SCA

Similar a los pasos anteriores solo que solo tenemos que especificar el servidor con el rol de Gateway:

Nos aparecerá el Sumario:

Y, nuevamente, nos va mostrando todos y cada uno de los chequeos que realiza y …. todo correcto, hay conexión con Azure:

Nos irán apareciendo todos los servidores en nuestra consola:

Ahora, podremos analizar el estado de nuestras configuraciones, cuándo ha habido cambios, sobre todo, como dice Kilian Arjona, para detectar si despues de un cambio tenemos un problemas, ver el estado de la replicación de nuestros Controladores de Dominio, etc., etc. Fijaros, 14 cambios en 2 servidores en los últimos 7 dias…..

DETALLES DE LA CONFIGURACION

Por un lado si nos fijamos en los servicios generados en los servidores al instalar los agentes, vemos que son los de SCOM:

Y, por otro, las rutas donde se ubican los logs son las siguientes:

Logs del Gateway.- C:\Program Files\System Center Advisor\GatewayData\Logs
Logs del Cliente.- C:\Program Files\System Center Advisor\AgentData\Logs

Lecturas recomendadas

Os dejo estos dos post muy buenos de dos maquinas, Kilian Arjona de Ncora y eManu, espectacular en la exposición. Poco o muy poco he podido aportar a lo dicho por ambos, solo la experiencia de instalarlo y echarle un vistazo.

– Blog de Ncora.

– Blog de eManu. (@emanu).

Ya queda muy, pero que muy poco para las vacaciones.

CA Directorio Activo IIS Powershell Servicios Windows Windows 2008 Windows 2008 R2 Windows 2012 Windows 2012 R2

Depromocionar un Controlador de Dominio que también es una Entidad Certificadora. Un poco mas dificil .. o no!

16/07/2014 Published by: Roberto Tejero

Hoy es dejo esta perlita informativa sobre cómo quitar un controlador de dominio que, además es la Entidad Certificadora, todo ello sin que haya pérdida del servicio, y vuelva a la normalidad, vamos, sin que pase nada, sobre un Windows Server 2003.

Los siguientes gráficos nos muestran cómo es la situación inicial y cómo queremos que sea la final, el camino ….. se hace al andar.

Antes

Despues

Nuestro objetivo es empezar a eliminar servicios publicados en Windows Server 2003 y elevar la funcionalidad de nuestro dominio DMZ.com a Windows Server 2008 R2 o superior.

Lo normal en estos casos es buscar un poco de información en Internet, como apoyo, ver HowTo, documentos, experiencias de otros Administradores. Si haces una búsqueda en Google sobre «Migrar entidad certificadora» aparecen los siguientes items:

Es un honor para mi compartir links de resultados con dos gurus de la tecnologia, maese Josep Ros (@josepros), y el Gran Bujarra 3.0, (Hector Herrero (@nheobug). Apuntaros sus twitters y sus blogs ya que son dos referentes del panorama IT en castellano.

Los pasos a seguir serán los siguientes:

Copia de seguridad de nuestra CA.
Eliminar el Rol de CA.
Realizar un DCPromo.
Volver a instalar el rol de CA.
Verificar el entramado

0 Realizar Copia de Seguridad de la Entidad Certificadora.

Este es el punto inicial para la gran mayoria de actuaciones, tener o realizar una copia de seguridad. Este punto ya lo hemos visto en un post del mes pasado «Migración de una Entidad Certificadora de Servidor. Parte I – Exportación«.

Migrate00007

Poco o nada puedo aportar. Hago un breve resumen:

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

1 Eliminar Rol de Entidad Certificadora (CA).

Como es un Windows Server 2003 desde Panel de Control, agregar o quitar programas, procedemos a eliminar el rol de Certificate services:

También se reconfigurarán los servicios de IIS

Y finalizará exitosamente:

Como veis, muy sencillo este paso.

2 Depromocionar el rol de Controlador de Dominio.

Lanzamos a nuestro gran amigo «DCPromo», ya desaparecido en Windows Server 2012 y 2012 R2, apareciéndonos el asistente de «depromoción» de Controlador de Dominio de Directorio Activo (AD):

En nuestro caso no es el último controlador del Dominio, asi que dejaremos en blanco esta selección:

Pondremos password a la cuenta de Administrador local del servidor, ahora que va a dejar de ser Controlador de Dominio:

Un pequeño detalle, puede aparecer que este Controlador de Dominio tambén sea Catálogo Global (GC), por lo que tendremos que quitar éste rol antes de proceder a realizar el Depromocionado. Continuamos y, nos informa que va a proceder a eliminar el rol de Controlador de Dominio del dominio DMZ.com:

Procederá a parar servicios como NETLOGON:

El servicio RPCLOCATOR:

Y eliminando LDAP así como RPC:

Nos informará, nuevamente, de que ha sido eliminado el rol de DC:

No hay que olvidarse que este proceso, obligatoriamente, requiere un reinicio:

O sea, este servidor ya no es ni Controlador de Dominio del dominio DMZ.com, ni Entidad Certificadora de dicho dominio, ya no es nadie, jejejeje.

3 Instalación del Rol Entidad Certificadora.

Llegamos al ecuador de nuestro post del dia. Ahora llega lo mas dificil. Ya hemos visto como montar un Entidad Certificadora en un post del mes pasado «Migración de una Entidad Certificadora de Servidor. Parte II – Importación«, concretamente en el primer punto de post veiamos como montar una CA sobre Windows Server 2008 R2, pero, en este caso es una CA en Windows Server 2003. Es muy parecido, por no decir que igual.

Desde Panel de Control, Agregar o quitar programas:

Seleccionaremos el rol de Certificate Services. Posteriormente nos aparecerá el tipo de Entidad Certificadora queremos instalar, en nuestro caso Enterprise root CA:

DesinstallCAwithDCPromo00019b

Continú la instalación y nos pregunta sobre la Clave Pública y la Clave Privada. Como hemos hecho una copia de seguridad en el paso Cero, lo podemos restaurar ahora, o cuando se termine de instalar el rol. Si restauraremos ahora la clave pública:

Nos informa de si queremos sobreescribir, ya que los ficheros existen del paso 1:

También podremos seleccionaremos nuestro CSP y el algoritmo Hash:

Nos informará sobre la identificación de nuestra Entidad Certificadora, Common name, Distinguished name y la validez de la misma:

Seleccionaremos las rutas de la base de datos y los logs. En la captura vienen las rutas por defecto:

Nos avisará que los servicios de IIS se pararán durante la instalación…

Reinstalación de los servicios de IIS:

Y ya está instalado el rol.

Como he comentado antes, podíamos realizar una instalación con todos los parámetros por defecto y posteriormente restaurar el backup y la clave del registro con toda la configuración que funcionará perfectamente, esta opción también la hemos comentado el mes pasado en el siguiente post «Migración de una Entidad Certificadora de Servidor. Parte II – Importación«. Aunque … Lo dejo a vuestra elección.

4 Chequeo de funcionamiento.

Nos faltaría realizar las comprobaciones pertinentes, os dejo los chequeos principales, que ya hemos visto en el Chequeo de la Entidad Certificadora:

Podemos acceder al certificado de la CA y comprobar todas sus características.
Que todos los certificados emitidos por la CA siguen funcionando correctamente.
Que podemos emitir nuevos certificados que sirven a su función.
Que vemos todas las plantillas que se publican en Directorio Activo.
Podemos ver todos los certificados revocados,
Podemos visualizar los certificados emitidos por la anterior CA.
Podemos acceder a la lista de revocación de certificados (CRL).
Comprobar todas las Extensiones tanto del Punto de distribución de la CRL como del Acceso a la Información de la Autoridad (AIA), etc.,

Y también nos faltaría realizar las comprobaciones pertinentes en los Controladores de Dominio:

Verificar el estado lanzando la herramienta DCDIAG.
Echar un vistazo a los visores de eventos tratando de encontrar algún error.
Verificar la replicación entre los Controladores de Dominio existentes, por ejemplo con repadmin o con «AD Replication Status Tool«
etc.

Pues ya estaría.

Si quería dejaros un pequeño listado de errores que me han aparecido en este proceso:

El Controlador de Dominio Windows Server 2003 también es Catálogo Global.- Tenemos que quitar el rol de Catálogo Global antes de realizar el DCPromo.

En el proceso de Depromocionar nuestro Controlador de Dominio nos ha dado un error de «time out» a la hora de reiniciar el servicio NETLOGON.- Esto es algo, relativamente normal. Así que vuelves a lanzar el proceso de DCPromo y solucionado.

Error a la hora de importar Backup de la Entidad Certificadora.- Suele pasar al tratar de restaurar un backup de la base de datos de la CA sobre un directorio que ya contiene datos. Tiene que estar en blanco.

Error de Caché en el Pool de Aplicación que utiliza la Entidad Certificadora.- Esto pasa porque el usuario con el que se ejecuta el Pool de Aplicación no tiene permiso en una serie de directorios de C:. Se dan los permisos y funcionando.

Todos ellos fáciles de solucionar. Para que luego digan que todo sale a la primera, o a la segunda. Normalmente hay que ir solucionando algún que otro error.

Espero que os haya gustado y, sobre todo, que os sea util. Buena semana a todos.

Referencias:

– Blog de Josep Ros.

– Blog del Bujarra 3.0.

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.

Planificacion Seguridad Servicios Windows Windows 2012 Windows 2012 R2

Migrar servicio WSUS desde Windows Server 2003 a Windows Server 2012 R2. Fase 2: Ejecución.

23/05/2014 Published by: Roberto Tejero

Buenos dias, por fin es viernes.

Hoy vamos a ver el paso a paso y el resultado de la migración de nuestro servicio WSUS.

Ya vimos en el post anterior denominado «Planificación» tanto los prerequisitos necesarios como los pasos que vamos a seguir, asi que ……. Rock & Roll.

1 Usuarios y Grupos Locales.

Recordamos que el servicio WSUS trabaja con usuarios/grupos locales así que tendremos que tenerlos en cuenta en la migración.

En nuestro caso todo lo gestiona un grupo de seguridad del Grupo de Atención al Usuario, tanto los Administradores como los Iformes. (tomamos nota).

Upgradewsus000003

2 Backup de la base de datos de WSUS.

Desde nuestro Microsoft SQL Server Management Studio Express del servidor origen, realizaremos la copia de seguridad. Seguiremos los siguientes pasos:

Nos conectamos a la instancia del servidor en el Explorador de Objetos de nuestra consola.
Expandimos la bases de datos (DDBB) y seleccionamos la DDBB denominada SUSDB (como puede verse en la captura).
Botón derecho, seleccionaremos Tareas (Tasks) y despues Back UP, donde tendremos que seleccionar los siguientes parámetros para nuestro backup: Base de Datos, tipo, que será Completo y ruta donde almacenar nuestra copia de seguridad.
Pulsaremos OK y ya tendremos nuestra copia de seguridad.

3 Instalación Microsoft SQL Express & Management Studio en el servidor destino.

Como ya hemos comentado, lo primero es tener instalado Microsoft SQL Express & Management Studio, asi que me pongo manos a la obra. Ya os facilité los diferentes links de descarrgas de las versiones así que os dejo un par de capturas de la instalación, el Wizard:

Y seleccionaremos las herramientas de gestión:

Os dejo abajo un link mucho mas exhaustivo y detallado de cómo instalar SQL Express Management Studio en las lecturas recomendadas.

Por cierto, al realizar la instalación de la versión 2012, probablemente os aparezca el siguiente error si no teneis instalado el .Net Framework 3.5

Lo solucionaremos como vimos hace poco en este post «No puedo instalar .Net Framework 3.5 en Windows Server 2012 y Windows Server 2012 R2. Una solución quiero!»

Upgradewsus000011B

4 Restauración de la base de datos de WSUS en el servidor destino.

Pasos a seguir:

Abrimos Microsoft SQL Management Studio y lo conectamos a la instancia local instalada en el punto anterior.
Expandimos las bases de datos.
Botón derecho sobre bases de datos y seleccionamos «Restaurar base de datos».
Seleccioanremos l
Se realiza la restauración.
Chin pun, finiquito.

Insisito, fácil

5 Instalación del Rol WSUS en el servidor destino.

Necesitaremos las siguientes características para la instalación del rol:

.NET Framework. (ya la hemos instalado en puntos anteriores).
Background Intelligent Transfer Service (BITS) 2.0.
Microsoft Internet Information Services (IIS).

Podemos instalarlas via PowerShell (PS) con el siguiente cmdlet:

Import-Module ServerManager

Add-WindowsFeature Bitstransfer IIS

O desde el Server Manager, al libre albedrío.

Despues, continuaríamos con los siguientes pasos:

ServerManager.
Añadir Roles y Características, donde seleccionamos WSUS.
Automáticamente nos aparecen los Roles y las Características necesarias para la instalación de WSUS, que os resumo

Upgradewsus000020b

4. Configuración inicial para la instalación del servicio WSUS.

5. Seleccionaremos, en nuestro caso, los siguientes roles:

6. Seleccionaremos la ruta donde se almacenarán las actualizaciones:

7. Apuntamos la conexión a la base de datos que acabamos de restaurar:

Se lanza la instalación de todos estos roles y características. Si os fijais, ya nos indica que existen unas tareas que tendremos que configurar una vez se haya terminado dicha instalación:

Una vez terminada la instalación, con o sin reinicio, realizamos las tareas post-despliegue:

8. Conectaremos la base de datos y el almacenamiento para las descargas del servicio WSUS:

Comprobaremos que todo ha sido correcto:

9. Se lanza el asistente de configuración del servicio WSUS (como si fuese la primera vez pero no lo es)

10. Elegiremos de dónde nos vamos a descargar los parches (al igual que el Servidor origen).

11. Comprobaremos credenciales, si son necesarias, para el acceso a internet:

Y ya estaría instalado el servicio

7 Cambio de WSUS server Identity

Como ya comentamos, nuestra intención es que los usuarios finales, ya sean servidores o clientes, no se vean afectados por este cambio. Ya sabemos que el servicio WSUS le asigna a cada servidor un GUID distinto al de AD y trabaja con él, lo que tenemos que hacer es que al cambiar de servidor y base de datos, el cliente final no se vea afectado perdiendo la conexión con el servicio WSUS.

1. En el nuevo servidor abriremos consola de PowerShell con privilegios de administrador.

2. Importaremos el módulo de WSUS.

2. Ejecutaremos el siguiente script:

$updateServer = get-wsusserver

$config = $updateServer.GetConfiguration()

$config.ServerId = [System.Guid]::NewGuid()

$config.Save()

Todo de una vez, para verlo mas claro:

Upgradewsus000032

4. Tan pronto la identidad haya cambiado, ejecutaremos el siguiente comando para generar una nueva clave de encriptación: WSUSUTIL.exe Postinstall

8 Usuarios y Grupos Locales.

Recordamos los usuarios que pertenecían a los gurpos de gestión del servicio WSUS y los introducimos desde el Server Manager:

9 Apuntar a todos los clientes a la nueva dirección del servidor WSUS.

Desde la consola gpmc.msc de gestión de Políticas de Grupo de Directorio Activo actualizaremos el Servidor que realiza las tareas de WSUS (Specify intranet Microsoft update service policy) en cada una de las GPOs de actualización de parches que existan:

Luego, para forzar a los clientes a detectar el nuevo servidor destino, desde una consola podemos ejecutar los siguientes comandos:

wuauclt.exe /resetauthorization /detectnow
GPUpdate /Force.

10 Verificar la configuración del servidor destino.

Comprobarermos el correcto funcionamiento de nuestro nuevo servidor. ¿cómo? realizando las siguientes comprobaciones desde la consola de gestión del servicio WSUS:

Expandiremos Equipos y verificaremos las últimas conexiones o reportes de cada equipo, si empiezan a actualizarse es que todo está correcto.

Realizaremos una sincronización con Microsoft Windows Update y verificaremos si es correcta.

Verificar si existen servidores réplica a los que nuestro nuevo servidor distribuye parches ya actualizaciones de seguridad:

11 Verificación de la funcionalidad del servicio WSUS en los clientes.

Podremos comprobar el funcionamiento correcto del servicio en el log que deja WSUS en cada cliente en la ruta%WinDir%\WindowsUpdate.log

Lecturas recomendadas:

Lo se, vaya ladrillo, pero ya sabeis que la realidad supera la ficción y la planificación.

Buen fin de semana.

Planificacion Seguridad Servicios Windows Windows 2012 Windows 2012 R2

Migrar servicio WSUS desde Windows Server 2003 a Windows Server 2012 R2. Fase 1: Planificación.

12/05/2014 Published by: Roberto Tejero

Otro de los muchos proyectos en los que estoy involucrado es la migración de todos los servicios que tengo instalados sobre Windows 2003 Server a Windows Server 2012 o Windows Server 2012 R2. En este caso voy a comentar los pasos a realizar para migrar el servicio Windows Server Update Services (WSUS). En este primero post vamos a planificar (ese gran desconocido) la migración, ya en un segundo post lo veremos mas a fondo, paso a paso, y, sobre todo, veremos el resultado.

Upgradewsus000002

Necesidades

Crear un nuevo servidor virtual con la siguiente configuración de Hardware:

SO: Windows Server 2012 o Windows Server 212 R2 Standard Edition
Memoria RAM: 2 GB (minimo).
vCPUs: 4
Discos: 2 discos, uno para el sistema operativo y otro para el servicio WSUS que suele crecer bastante si no lo gestionamos bien.

Preprequisitos

Recolectar información sobre los servidores involucrados, dirección IP, nombre e instancia de la base de datos WSUS, servicios y usuarios involucrados, etc.
Descargar e instalar Microsoft SQL Server Management Studio en los servidores Origen (Servidor A) y destino (Servidor B).
No lanzar la instalación inicial del rol WSUS sobre el servidor destino.
Verificar que no vamos a instalar el servicio sobre un Controlador de Dominio,
Que el servidor destino esté en dominio y sincronizado en hora con el PDC.
Tener los permisos necesarios tanto en origen como en destino para realizar todas estas tareas.

Los pasos planificados a seguir son los siguientes:

1 Usuarios y Grupos Locales.

El servicio WSUS trabaja con usuarios/grupos locales así que tendremos que tenerlos en cuanta en la migración.

2 Backup de la base de datos de WSUS.

Desde nuestro Microsoft SQL Server Management Studio Express, podremos realizar la copia de seguridad de la base de datos de WSUS (Links de descargar version 2005, 2008 y 2012).

3 Restauración de la base de datos de WSUS en el servidor destino.

Es el paso inverso al anterior. En principio no tiene porque darnos ningún problema.

4 Instalación del Rol WSUS en el servidor destino.

Ya en el servidor destino con Windows Server 2012 o Windows Server 2012 R2, necesitaremos las siguientes características para la instalación del rol:

.NET Framework. (ya la hemos instalado en puntos anteriores).
Background Intelligent Transfer Service (BITS) 2.0.
Microsoft Internet Information Services (IIS).

5 Cambio de WSUS server Identity

La intención es que los usuarios finales, ya sean servidores o equipos clientes, no se vean afectados por este cambio. Ya sabemos que el servicio WSUS le asigna a cada servidor un GUID distinto al de AD y trabaja con él, lo que tenemos que hacer, a través de un script de Powershell, cambiar la identidad del servidor WSUS y generar una nueva clave de cifrado.

6 Apuntar a todos los clientes a la nueva dirección del servidor WSUS.

Se trataría de cambiar la URL en las distintas GPOs que tengamos configuradas en nuestros dominios. Muy sencillo.

7 Verificar la configuración del servidor destino.

Comprobar el correcto funcionamiento de nuestro nuevo servidor.

8 Verificación de la funcionalidad del servicio WSUS en los clientes.

Podremos comprobar el funcionamiento correcto del servicio en el log que deja WSUS en cada cliente en la ruta%WinDir%\WindowsUpdate.log

Y poco mas. Como veis son 8 pasos bastante sencillos. Me gustaría tener el segundo post para finales de esta semana, ya se verá.

Lecturas recomendadas:

Y también os dejo este video, espero que os sea util:

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.

El camino de un ITPro