Archivo de la categoría: Servicios Windows

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


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.

sca000001

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:

sca000003

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:

sca000005

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:

sca000006

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:

sca000007

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:

sca000010Aceptaremos los términos de la licencia:

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

sca000012

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

sca000013

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

sca000014Siguiente, ….

sca000015

sca000016Listos para empezar a instalar:

sca000017

Instalando, que es gerundio …

sca000018

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:

sca000022

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

sca000023

Nos confirmará los pasos a seguir:sca000024

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

sca000025

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

sca000026

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:

sca000031

Nos aparecerá el Sumario:

sca000032

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

sca000033

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

sca000036

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…..

sca000037

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:

sca000034

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

  • Logs del Gateway.- C:Program FilesSystem Center AdvisorGatewayDataLogs
  • Logs del Cliente.- C:Program FilesSystem Center AdvisorAgentDataLogs

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.

Anuncios

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


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

Antes

Despues

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:

Migrate00001

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:

DesinstallCAwithDCPromo00001

También se reconfigurarán los servicios de IIS

DesinstallCAwithDCPromo00002

Y finalizará exitosamente:

DesinstallCAwithDCPromo00003

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

DesinstallCAwithDCPromo00004

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

DesinstallCAwithDCPromo00006

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

DesinstallCAwithDCPromo00007

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:

DesinstallCAwithDCPromo00008

Procederá a parar servicios como NETLOGON:

DesinstallCAwithDCPromo00009

El servicio RPCLOCATOR:

DesinstallCAwithDCPromo00012

Y eliminando LDAP así como RPC:

DesinstallCAwithDCPromo00013

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

DesinstallCAwithDCPromo00014

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

DesinstallCAwithDCPromo00015

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:

DesinstallCAwithDCPromo00017

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:

DesinstallCAwithDCPromo00020

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

DesinstallCAwithDCPromo00021

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

DesinstallCAwithDCPromo00022

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

DesinstallCAwithDCPromo00023

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

DesinstallCAwithDCPromo00024

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

DesinstallCAwithDCPromo00025

Reinstalación de los servicios de IIS:

DesinstallCAwithDCPromo00026

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.

DesinstallCAwithDCPromo00005

  • 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.

DesinstallCAwithDCPromo00010

  • 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.

DesinstallCAwithDCPromo00033

  • 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.

DesinstallCAwithDCPromo00035

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.

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


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:

Migrate00002

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:

Migrate00004

Ponemos una password para securizar la copia de seguridad:

Migrate00005

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>

Migrate00010

Para terminar realizamos una copia de seguridad de la configuración del registro de la CA que se encuentra ubicada en HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvcConfiguration. 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

Migrate00012

Desde línea de Comando:

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

Migrate00011

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.

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


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:

  1. Nos conectamos a la instancia del servidor en el Explorador de Objetos de nuestra consola.
  2. Expandimos la bases de datos (DDBB) y seleccionamos la DDBB denominada SUSDB (como puede verse en la captura).
  3. 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.
  4. Pulsaremos OK y ya tendremos nuestra copia de seguridad.

Upgradewsus000008

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:

Upgradewsus000006

Y seleccionaremos las herramientas de gestión:

Upgradewsus000007

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

Upgradewsus00000

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:

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

Upgradewsus000012

Insisito, fácil

Upgradewsus000014

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).Upgradewsus000015
  • 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 IISUpgradewsus000017

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

Despues, continuaríamos con los siguientes pasos:

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

Upgradewsus000018bUpgradewsus000020b

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:

Upgradewsus000021

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

Upgradewsus00002

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:

Upgradewsus000022

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

Upgradewsus000023

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

Upgradewsus000026

Comprobaremos que todo ha sido correcto:

Upgradewsus000027

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

Upgradewsus000028

Siguiente:

Upgradewsus000029

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

Upgradewsus000030

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

Upgradewsus000031

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:

Upgradewsus000061

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:

Upgradewsus000034

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.

Upgradewsus000062

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

Upgradewsus0000101

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

Upgradewsus000063

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.

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


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.Upgradewsus000003

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:

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


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).CreacionFailoverCluster000001
  • 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.

CreacionFailoverCluster000002

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.

CreacionFailoverCluster000003

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

CreacionFailoverCluster000004

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>

CreacionFailoverCluster000010

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

CreacionFailoverCluster000011 CreacionFailoverCluster000012

Que, por defecto, nos lo ubicará en c:\windows\Cluster\Reports :

CreacionFailoverCluster000013

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.

CreacionFailoverCluster000014

Si hacemos un Windows Update nos aparece lo siguiente:

CreacionFailoverCluster000015

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>

CreacionFailoverCluster000020

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

CreacionFailoverCluster000019

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:

CreacionFailoverCluster000021

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’

CreacionFailoverCluster000022

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

CreacionFailoverCluster000023

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’

CreacionFailoverCluster000024

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:

CreacionFailoverCluster000025

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’

CreacionFailoverCluster000026

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:

CreacionFailoverCluster000027

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.

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


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.

RPCPORTS00001

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_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters y añadimos la clave DWORD TCP/IP Port con el valor del puerto que queremos utilizar (incluyendo los espacios en blanco).
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 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

RPCPORTS00002

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

RPCPORTS00003

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_MACHINE\Software\Microsoft\Rpc

  1. 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:

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


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

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:

ClusterServidorFicheros000069

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:

ClusterServidorFicheros000001

Indicamos que va a ser un disco en modo  RAW:

ClusterServidorFicheros000002

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

ClusterServidorFicheros000003

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:

ClusterServidorFicheros000004

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

ClusterServidorFicheros000005

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:

ClusterServidorFicheros000006

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:

ClusterServidorFicheros000006b

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

ClusterServidorFicheros000070

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:

ClusterServidorFicheros000008

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:

ClusterServidorFicheros000009

Volvemos a seleccionar los nodos SCSI virtuales:

ClusterServidorFicheros000011

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:

ClusterServidorFicheros000010

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”.

ClusterServidorFicheros000072

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:

ClusterServidorFicheros000073

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

ClusterServidorFicheros000074

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.

masrobeznoquenunca

Comparto lo que hago y lo que veo.

El camino de un ITPro

El camino de un ITPro

adumont

Just another WordPress.com weblog

Marco Antonio's space

Una mirada dentro de mis ratos libres...

Marcelo Ruiz

Network and SocialMedia

A Digital Frontier...

Blog personal de Robert Garrandés Simancas ("Versión Beta")

enero11

Literatura para romper el tiempo.

A %d blogueros les gusta esto: