Por fin ya salió definitivo el Service Pack 2 para Windows Server Update Services (WSUS). Ya lo había anunciado en artículos pasados pero ahora ya está disponible para bajar e instalar a todo el público. Realmente recomiendo hacerlo, todavía no hay problemas reportados con la aplicación de este service pack, pero si hay varios casos de instalación exitosa. Es mas, ni siquiera requiere reiniciar el servidor así que lo podes hacer cuando quieras.

Si no tenes instalado el WSUS con este mismo ejecutable podes hacerlo al igual como se hacía con el Service Pack 1. Este SP2 agrega algunas nuevas funcionalidades y mejora otras. Por ejemplo:

Integración con Windows Server 2008 R2.
Soporte de la función BranchCache en Windows Server 2008 R2.
Soporte para clientes Windows 7 y Windows Server 2008 R2.
Reporte de Compliance.
Mejoras de performance, experiencia con el usuario y algunos errores solucionados para el Windows Update Agent (WUA).

Estas son algunas de las mejoras, en el link del WSUS Team Blog vas a encontrar el listado completo de las mismas y realmente recomiendo que lo instales cuanto antes y empieces a utilizarlas.

Ahora para instalar este update en un Small Business Server (SBS) hay que tener algo de cuidado, es mas, recomiendo revisar el link que dejo mas abajo donde explica exactamente lo que deben hacer y cómo para tener una instalación exitosa del producto.

Cualquier problema o duda recomiendo que sigan este tema en el Foro de WSUS donde hay secciones específicas para cada uno de los problemas.

Link | WSUS Team Blog
Link | Installing Windows Server Update Services 3.0 on Windows Small Business Server 2003
Link | Description of Windows Server Update Services 3.0 Service Pack 2
Link | Windows Server Update Services 3.0 SP2 Dynamic Installer for Server Manager
Link | Descargar WSUS 3.0 SP2
Link | Foro de WSUS en Español

Ya había hecho algunos comentarios sobre las novedades en cuanto al servicio de Hyper-V para la nueva versión de Windows Server 2008. Pero este sistema operativo ofrece otros servicios que también sufren modificaciones o nuevos features y la idea era comentar algunos de ellos porque estan muy buenos y si hoy estas usando Windows Server 2008 en tu ambiente seguro vas a querer actualizarte al R2. Si en cambio todavía tenes 2003, actualizate YA!, me lo vas a agradecer.

Active Directory PowerShell cmdlets: Como el nombre lo dice, son nuevos cmdlets administrativos en PowerShell para Active Directory.

Active Directory Best Practice Analyzer: Por fin un buen BPA para Active Directory completo que nos puede decir donde está el error de configuración.

Active Directory Web Services (ADWS): Es un nuevo servicio de un Domain Controller que sirve como interfaz web entre las instancias que corren de AD, LDS, etc. Si este servicio se para o se deshabilita, ya que se instala por defecto, algunas instancias como el Administrative Center o el PowerShell module no funcionaran.

Active Directory Administrative Center: Ahora podemos administrar el Active Directory desde una nueva GUI mucho mejor que el anterior ADUC que sigue estando, pero esta nueva consola basada en scripts PowerShell nos da la oportunidad de administrar el AD centralizadamente de forma simple para las tareas rutinarias.

Offline Domain Join: Ahora vamos a poder programar las PCs para que ingresen al dominio sin necesidad de realmente hacerlo y cuando la PC inicie por primera vez se va a agregar sola. Esto sirve para deploys masivos.

Active Directory Recycle Bin: Obviamente si traducimos el nombre sabemos para que sirve. Cuántas veces vemos que eliminan cuentas de usuario y después tienen que hacer un restore para poder recuperarlo? Ahora podemos hacerlo de una manera mucho mas simple ya que queda en una papelera de reciclaje de AD. Acá les dejo un gráfico que muestra la vida de un objeto en el Active Directory con el Recycle Bin activado.

 
Active Directory Certificate Services (AD CS): ahora permite una implementación mas flexible de una infrasestructura PKI, reduce administración y soporta NAP.

Windows AppLocker: Este features es nuevo tanto en Windows Server 2008 R2 como en Windows 7 reemplaza las políticas de restricción de Software. Sigue basado en reglas que uno puede exportar e importar.

Biometrics: Windows 7 soporta habilitar biometrics para la autenticación como por ejemplo a través de un lector de huellas digitales y poder elevar privilegios con el UAC. Esta configuración puede ser enviada por GPO.

DNS: Siiii algo nuevo en el DNS también, ahora soporta Domain Name System Security Extensions (DNSSEC). Ahora con Windows Server 2008 R2 podemos firmar y hostear zonas firmadas-DNSSEC y darle seguridad al ambiente. Soporta los registros DNSKEY, RRSIG, NSEC y DS.

Failover Clusters: Algunas mejoras en el proceso de validación de un cluster nuevo o existente. Las mejoras de Cluster con Virtual Machines a través de Hyper-V que ya había comentado antes. La interfaz PowerShell para la administración del servicio, y mejoras en la posibilidad de migrar las configuraciones de un cluster a otro.

Hyper-V: Ya lo comenté mas en detalle antes, pero está Live Migration, Enhanced Processor Support, Enhanced Networking Support, Dynamic Virtual Machine Storage, etc.

Group Policy: No hay muchos cambios, si a nivel administrativo gracias a los Cmdlets de PowerShell, algunos ítems nuevos de Group Policy Preferences, mejoras en las Starter GPO’s, y otros administrative settings adicionales.

Network Access Protection (NAP): Multi-Configuration SHV que simplemente permite la configuración de múltiples System Health Validators (SHV). En cuanto al cliente NAP tiene algunas mejoras para Windows 7.

Network Policy Server (NPS): La administración de los templates y los templates de NPS son uno de las nuevas características. Esto permite generar la configuración para un determinado servicio o server y reutilizarlo en otro equipo o en el mismo equipo local. También hay mejoras en el accounting del RADIUS que permite configurar un SQL para guardar los logs.

Networking: Hay varias mejoras en cuanto a networking tanto para Windows Server 2008 R2 como para Windows 7. Algunas de ellas son, Direct Access que permite conectarte a la red de tu compañía sin necesidad de iniciar una VPN antes. VPN Reconnect, que simplemente si se cayó la conexión de VPN la vuelve a iniciar. BrandCache que como el nombre lo dice, hace un caché de archivos y webs a través de una WAN. URL QoS con el que podemos definir prioridad según la URL desde donde se origine el tráfico. Multiple active firewall profiles, con el que cambiará las reglas de firewall según la red a la que estemos conectados.

Server Manager: Podemos administrar servidores remotamente desde la consola de Server Manager. Best Practice Analyzer (BPA) para determinados roles y features. Nuevos PowerShell Cmdlets propios de Server Manager como por ejemplo Add-WindowsFeature. WSUS está disponible como rol desde el Server Manager. Y obviamente la posibilidad de agregar o configurar los nuevos features comentados acá.

Web Server (IIS): Este también sufrió grandes cambios, IIS 7.5 ahora tiene nuevos features y mejoras en WebDAV y FTP, los módulos de administración, Best Practice Analyzer (BPA), PowerShell, Hostable Web Core, FastCGI y .NET en Server Core. En el link del final del artículo podes leer todas las características completas.

PowerShell: Este si que tuvo cambios. Obviamente nuevos Cmdlets, administración remota, Windows Integrated Scripting Environment (ISE) que es una interfaz gráfica para poder armar scipts complejos con PowerShell. Background Jobs permite ejecución de trabajos en el background como lo dice su nombre, Debugger con el que podremos hacer un debug de las funciones o scripts que armemos, Eventos, Funciones Avanzadas, Internacionalización, etc.

Windows Security Auditing: Mejoras en cuanto a la auditoría donde ahora ofrece mucho mas detalle. Muchas mas políticas de auditoría para configurar que antes a través de GPOs o políticas locales. Nuevos SACLs y ACEs que van a ayudar a hacer tu vida mas fácil.

Remote Desktop Services: Este si que es largo de comentar. Para empezar sabemos que cambió el nombre obviamente del anterior Terminal Services a Remote Desktop Services. Muchísimas mejoras de performance en la experiencia del usuario, compatibilidad con Windows Installer RDS, administración de la caché de los perfiles de usuarios roaming.  No soporta mas el descubrimiento automático de servidores de licencias, la administración de CALs, mejoras en cuanto a la parte de networking y WAN, etc. También se integra con Hyper-V para brindar RemoteApp y RemoteDesktop a las máquinas virtuales. Remote Desktop Client 7.0 soporta Aero en las sesiones de Windows 7 y Windows Server 2008 R2.

Creo que con todo esto tenes un panorama general de las nuevas funciones, ahora sólo queda probarlas y ver si podes implementarlas en tu ambiente. Te dejo el link completo de Technet con el detalle de cada uno de estos servicios así podes leer mas a fondo el que mas te interese.

Link | What’s New in Windows Server 2008 R2 (Beta)

A partir del 26 de Enero se encuentra disponible el programa de la BETA del Service Pack 2 (SP2) de WSUS 3.0 a través de Microsoft Connect. Para participar necesitas una cuenta Passport, ingresar al sitio de Connect de Microsoft y ahí suscribirte en la participación de dicha Beta. Lo importante es que puedas aportar información del producto para que pueda tener la mayor cantidad de mejoras posibles.

Entre los nuevos features y mejoras que trae el SP2 estan:

Soporte de Nuevas Versiones de Windows
·       Integration with Windows Server® 2008 R2
·       Support for Windows 7® client
·       Support for the BranchCache feature on Windows Server® 2008 R2

Reglas de Auto-Aprobación
·       New functionality lets you specify the approval deadline date and time.
·       You can now apply a rule to all computers or to specific computer groups.

Actualización de Archivos e Idiomas
·       This release provides improved handling of language selection on downstream servers. A new warning dialog appears when you download updates only for specified languages.

Compatibilidad entre Versiones
·       The user interface is compatible between Service Pack 1 and Service Pack 2 for WSUS 3.0 on both the client and the server.

Actualización de Software
·       Stability and reliability fixes for the WSUS server, such as support for IPV6 addresses greater than 40 characters.
·       The approval dialog now sorts computer groups alphabetically by group name.
·       Computer status report sorting icons are now functional in x64 environments.
·       Fixed setup issues with database servers running Microsoft® SQL Server® 2008.

Estoy esperando ansioso que salga la versión definitiva de este SP2 para poder hacer un deploy masivo en todas las implementaciones ya que las pruebas que he hecho hasta ahora salieron bastante bien. Si trabajas diariamente con el WSUS te sugiero que lo bajes y lo pruebes y cualquier comentario lo subas a la página de Microsoft Connect ya que ahí podrán resolver cualquier inquietud.

Muchas veces tenemos un problema en los equipos clientes que empiezan a aparecer y desaparecer de la consola, o sino puede que nunca aparezcan en la consola de WSUS. Algunas veces se debe al servicio de Windows Update en la misma PC, pero otras veces puede deberse a que el cliente fue clonado. Cuando alguien clona un equipo y éste ya se había conectado al WSUS puede que mantenga el mismo ID en los equipos y esto genera una especie de conflicto lo que hace que el mismo no aparezca en la consola. Otro comportamiento es que a veces aparezca uno de los equipos y otro día otro y hace que el anterior desaparezca misteriosamente.

Tal vez tengas este comportamiento pero no hayas clonado el equipo o no estes seguro, igualmente puedes probar si esto resuelve tu problema de conexión de los equipos a la consola de WSUS. Para estos casos cree un script que simplemente borra algunas entradas del registro que se van a regenerar cuando se vuelva a conectar con el servidor de WSUS. Si el ID está repetido le asignará uno nuevo y así no tendremos mas este problema.

Si tu problema es general también se puede asignar este script a una política (GPO) de dominio y así te aseguras que le corra a todos los equipos. También podrías agregar un flag para que no corra mas de una vez sino estaría borrando las entradas en cada logon. El flag puede ser un archivo o una entrada, cualquier condición que haga que no corra dos veces.

Para poder usar el script copiá y pegá el contenido que paso a continuación en un notepad, grabalo con extensión .cmd o .bat y luego lo ejecutas o lo asignas a una GPO. Luego de eliminar las entradas en el registro se reconecta con el servidor de WSUS y regenera la autorización con el mismo.

@echo off

REM WSUS: Script para Eliminar entradas en el Registro por Clonado de Equipos

net stop wuauserv

REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f

REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f

REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f

REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SUSClientIDValidation /f

net start wuauserv

wuauclt /resetauthorization /detectnow

exit

El toolkit que liberó Microsoft permite a los usuarios y administradores configurar las PCs para que no se les instale el Internet Explorer 8 como parche de seguridad detectado por Windows Update. Recordemos que esto pasó con Internet Explorer 7 también y es importante porque si las PCs se actualizan a IE8 y luego las aplicaciones de negocio no funcionan o no son soportadas puedes tener un gran problema en la compañía.

Lo bueno es que la distribución de dicho Toolkit es bien simple y hasta trae un archivo .adm para que podamos hacer dicha configuración via GPO en nuestro ambiente.

El Internet Explorer 8 va a ser liberado por Microsoft como un parche de seguridad con alta prioridad, así que si no tenes este toolkit instalado y tenes configurado para que el Automatic Updates chequee e instale lo que encuentre seguramente se te va a instalar. En una compañía con WSUS tenes dos cosas a tener en cuenta, esta por un lado para las PCs y no aprobarlo en el WSUS en primera instancia. Ojo los que lo tienen en forma de aprobación automática.

Aparentemente Microsoft dice que el IE8 es mucho mejor que el IE7 pero al liberarlo así no deja suficiente tiempo a las empresas a testearlo con sus aplicaciones y herramientas por eso que también ellos mismos liberaron este IE8 Blocker Toolkit.

La pantalla de instalación será similar a la del IE7 y el mismo sale para todas las versiones de sistema operativo, por lo que seriamente te recomiendo que actualices tu sistema con el Blocker Toolkit si es que no queres que se instale automáticamente.

Mas información sobre este desarrollo podes encontrarlo en el Blog del IE8 bajo el siguiente Link ».

Ahora hablando del Toolkit en si que se encuentra en la página de Downloads de Microsoft viene con un script ejecutable y un archivo adm como comentaba antes. El script crea la siguiente entrada de registro en el equipo destino:

Llave: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Setup\8.0
Valor: DoNotAllowIE80

Si el valor es 1 está bloqueada la distribución en ese equipo, si el valor es 0 o no está definido entonces no está bloqueado el equipo de recibir el IE8. El comando puede ser ejecutado de la siguiente forma:

IE80Blocker.cmd [Nombre de PC] [/B] [/U] [/H]

Si no se pone nombre de equipo correrá en forma local por lo que también se puede utilizar en forma de distribución o masiva este script. Con el /B se bloquea la distribución, con el /U se desbloquea y el /H es la ayuda.

El que utilice el .ADM en sus servidores de dominio para distribuirlo por GPO va a encontrar estos parámetros, luego de cargar el archivo, en:

"Computer Configuration / Administrative Templates / Windows Components / Windows Update / Automatic Updates Blockers"

Para mas información les recomiendo que revisen el link del Blog del IE y el link para bajar el Toolkit donde podrán encontrar esta info y mas.

Link | Download Toolkit to Disable Automatic Delivery of Internet Explorer 8

Al instalar/administrar WSUS o SCCM se pueden encontrar con ciertos problemas típicos que la idea es comentar algunos con sus respectivas soluciones así no deben estar buscando por toda la web.

Para empezar SIEMPRE verifiquen que tienen todos los componentes de software requeridos y mínimos instalados. Esto es muy importante, no sólo para las versiones de servidor o motores de base de datos sino para las consolas de administración. Es muy común que la instalación de la consola de SCCM no instalemos los requisitos mínimos que nos pide el instalador y que sigamos adelante en el asistente. Esto puede traer muchos problemas a la hora de querer conectarnos con nuestro Site Server.

Lo mismo para el WSUS, recuerden instalar todos los componentes requeridos ya que sino algunos módulos pueden no funcionar como corresponde. Creo que esto es la base de todo este artículo, tener todos los componentes de hardware y software al día y como la documentación dice que debemos tenerlo.

Algunos de estos puntos de problemas y soluciones no fueron realizados por mi, yo solo hice la compilación de los mismos de diferentes newsgroups y foros y los traduje ya que la mayoría estan en otros idiomas. Otros si me encontré con el problema yo y pongo mi solución al respecto.

1) Algunos clientes de SCCM no pasan un Status correcto al Servidor

Esto puede afectar tanto al status de SCCM como al status de los parches. Para la parte de los parches debemos verificar que la política de WSUS esté aplicada dentro de la siguiente entrada de registro:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer

Ahora bien, si además de eso no pasa un correcto status del cliente de SCCM al SCCM entonces puede deberse a algún problema con el cliente. Para esto tenemos dos opciones, podemos enviar una nueva instalación del mismo desde la consola y poner que haga una instalación o reparación y si eso no lo soluciona ir y trabajar sobre la PC de la siguiente forma:

1. Ejecutar ccmclean o ccmsetup /uninstall para desinstalar el cliente de SCCM.
2. Luego elminar el archivo C:\Windows\smscfg.ini
3. Eliminar las entradas de registro HKLM\SOFTWARE\Microsoft\CCMSetup y \SMS.
4. Eliminar las carpetas System32\CCMSetup y CCM
5. Eliminar el equipo de la consola de SCCM.
6. Reiniciar el equipo y dejar que la query de AD lo encuentre y enviar la instalación del agente nuevamente.

Esto debería republicar el cliente en la consola. Si es así podemos revisar si las políticas de WSUS aplicaron verificando la misma entrada de registo que antes.

2) Al querer instalar SCCM nos pregunta de hacer upgrade

Esto se debe a que en algun momento estuvo instalado SMS 2003 y no fue removido correctamente. No sólo hay que remover los objetos que detallo a continuación sino que hay que seguir la documentación para extender el schema en un ambiente que alguna vez tuvo SMS 2003 y no es el mismo comando que si lo hicieses por primera vez, ojo con eso porque también es un error común.

1. Instala las Support Tools del CD de Windows Server 2003 en un Domain Controller.
2. Luego ejecuta adsiedit.msc para editar la base de datos del Active Directory
3. Ir hasta “DC=dominio,DC=com” –> “CN=System”, y revisar si existe “CN=System Management”. Si existe, eliminarlo junto con sus subcarpetas
4. Eliminar las cuentas creadas por SMS en el Active Directory
5. Una vez que replique esta información sólo deben extender el Schema correctamente y listo ya pueden iniciar la instalación sin problemas.

3) El paquete de Windows Update no fue instalado

Este paquete puede llegar a requerir alrededor de 60 minutos para poder ser utilizado.  Si se espera dicho tiempo o se extiende un update a 60 minutos seguramente se aplicará sin problemas. 

4) No veo la notificación de los parches en las PCs

Esto generalmente es un error de configuración, ya sea por GPO o por Registry de las PCs. Para ver el cuadro de notificación la GPO o el registro deben estar configurados en “2- Notify for download and notify for install” o en “3- Auto Download and Notify for Install”. Luego de revisar estos ítems podes revisar el log en la PC para ver como está aplicando. 

Creo que estos son algunos de los ítems mas comunes, podemos encontrar otros pero bueno los dejo para otros artículos así no lo hago mas extenso.

Bueno, ya había hecho un artículo parecido para System Center Essentials, pero en esta ocasión nos referimos al producto System Center Configuration Manager (SCCM) 2007 que sería la nueva versión del SMS que seguramente les debe sonar un poco mas. No cubrí la instalación, prometo instalarlo en un laboratorio para comentarles los pasos pero me pareció mas interesante comentar cuales son los primeros pasos luego de haber instalado todos los componentes.

Algunos de los features funcionan inmediatamente luego de la instalación inicial, pero otros features requieren configuración extra.

Primeros Pasos de Configuración

Uno de los primeros pasos es configurar el Management Point, aunque este paso se puede hacer durante la instalación, así que vamos a asumir que lo hicieron en el setup. Qué es el Management Point? Digamos que es el punto de comunicación entre los clientes y los servidores de Configuration Manager 2007. En caso de que hayas hecho un Custom Setup en el asistente inicial, para pode agregar este rol debes ir a la consola de administración de SCCM, ahí en Site Database, luego Site Management, ingresas a tu Site Code – Site Name, ahí Site Settings, luego Site Systems y ahí hacé botón derecho sobre el servidor que queres que tenga el rol de Management Point y hacé click sobre New Roles para que inicie el asistente.

Como segundo paso deberíamos configurar los Boundaries que traducido serían como Fronteras o Sites que vamos a manejar. Existen diferentes formas de dar de alta los Boundaries, puede ser por Subnets enteras, rangos de IP, Sites de AD, etc. En mi caso voy a usar los Sites de Active Directory porque estan correctamente configurados y al día. Si no tenes configurados los Sites de Active Directory entonces no te recomiendo esta solución, tal vez te convenga usar Subnets para esto. Básicamente le va a decir los lugares donde puede buscar equipos y a qué Configuration Manager pertenece. Para agregar un nuevo Boundary debemos ir a la consola de SCCM –> Site Database –> Site Management –> Site Code –> Site Name –> Site Settings –> Boundaries y ahí podemos hacer botón derecho New Boundary o bien en las acciones del panel de la derecha.

En la tercera posición puede ser que en algunos casos requiera configurar un Server Locator Point. Este rol se puede necesitar para que algunos equipos encuentren el Management Point en caso de no pertenecer al dominio, por ejemplo. Si no das servicio a otro forest o no tenes equipos en workgroup entonces no hace falta este rol instalado.

En cuarto puesto podemos configurar el Fallback Status Point y Reporting Point. La razón por la cual podemos requerir tener un fallback status point es si queremos que los clientes reporten cualquier error a nuestro servidor de SCCM. Esto va de la mano con el Reporting point porque si queremos usar los reportes para ver los errores por ejemplo, necesitamos tener implementado el Fallback. Ahora bien, la razón por la cual lo configuramos en esta etapa es simplemente para que se configure en los clientes apenas los descubrimos y no necesitamos hacerlo luego. Para poder configurarlo es agregar un nuevo Rol al equipo que querramos designar con el mismo los pasos para llegar al asistente del nuevo rol están en el primer punto. Al llegar abrirá el asistente de configuración del mismo.

Al marcar ambos roles en el asistente vemos que se agregan ítems en el asistente. En la primer ventana debemos configurar el nombre del folder que usará para Reporting Point y en la segunda nos pregunta por unos parámetros de performance del servicio de Fallback como la cantidad de mensajes y el umbral del intervalo en segundos.

El siguiente paso sería instalar los Clientes de las diferentes formas que nos permite hacerlo y por último configurar algunos de esos agentes de los clientes. Pero vamos a ir mas allá y vamos a revisar algunas configuraciones extra.

Algunos de los ítems que vamos a revisar estan dentro de Site Database –> Site Management –> Site Code – Site Name –> Site Settings –> Component Configuration.

Por ejemplo el Management Point Component, si ingresamos a las propiedades vamos a poder revisar que exista un Management Point o bien configurar el balanceo de carga mediante Network Load Balancing.

Esto último por si queremos usar un nombre de DNS para apuntar al punto de administración o bien a través de la IP del Cluster de NLB.

Recuerda que mas arriba te explico el por qué es necesario un Management Point en el ambiente de SCCM. Es importante que este punto quede bien configurado porque afecta toda la implementación.

Ahí mismo tenemos también para seleccionar Software Distribution e ingresar a las propiedades. 

Aquí vamos a poder configurar la unidad donde van a estar alojados los paquetes de software que luego podemos enviar mediante la SCCM. En la otra solapa Distribution Point, tenemos algunos parámetros de performance, como por ejemplo cuantas distribuciones concurrentes, cuantos reintentos, cuanto delay para cada reintento, etc.

Incluso tenemos un tilde para marcar para que envíe el paquete del site mas cercano al equipo al que se está haciendo deploy.

Cuando nos topemos con Software Update Point Component, vamos a ver que no hay mucho para configurar y la gran mayoría de ítems están grisados. Sin embargo nosotros tenemos el WSUS 3.0 SP1 instalado en el mismo equipo que el SCCM entonces debe faltar agregar el Rol al mismo servidor. Vamos a nuestro servidor o bien agregamos otro y le agregamos el rol requerido.

Algunas de estas preguntas ya las respondimos si configuramos el WSUS directamente al instalarlo, pero igualmente debemos responderlas. La siguiente pantalla es importante porque vamos a definir el SCCM como punto de Software Update y bajo qué puertos por si configuramos el WSUS en otro puerto diferente durante la instalación. El resto de las pantallas son comunes a WSUS así que seguramente ya las conoces en su totalidad.

Una vez que terminamos de agregar el rol de Software Update vamos a ver los ítems que antes estaban grisados como activados y vamos a poder modificar los ítems que necesitemos.

Recuerden habilitar este rol sino no habrá Software Update desde su SCCM.

Para el caso que el WSUS esté configurado mediante SSL ese certificado debe ser agregado al SCCM. Recordemos que los clientes requieren el Windows Update Agent 3.0 para poder comunicarse con esta versión de WSUS y funcionar correctamente con todos los features.

Luego nos quedarían algunos puntos a configurar como los agentes de inventario tanto de Hardware como de Software. Las configuraciones para instalación de sistemas operativos completos desde la consola de SCCM y la parte de Reportes, pero todo eso sería mas interesante configurarlo en un segundo artículo. Por lo pronto vamos a ver cómo instalar el agente de SCCM en un cliente particular.

Instalando el Agente a un Cliente por GPO

Antes de hacer un deploy del agente en un equipo primero hay que configurar los agentes en la consola de SCCM. Esto se hace bajo Site Database –> Site Management –> Site Code – Site Name –> Site Settings –> Client Agents. Aquí vamos a encontrar los parámetros de los agentes para instalar en los clientes como los de inventario, software update, etc. Una vez que esos agentes están configurados podemos instalar el primer cliente.

Existen muchos métodos para hacer el deploy de los clientes, desde scripting, a directamente en la imagen de la PC, instalación manual, GPO, etc. En este caso lo vamos a hacer por GPO que como no se puede enviar configuración adicional debe estar publicado el SCCM en el Active Directory de lo contrario no encontrará la implementación.

Lo que podemos hacer es Asignar o Publicar el archivo CCMSETUP.MSI que encontramos en SMSSETUP\BIN\I386 del dispositivo de instalación.

Asignando este paquete el equipo estará disponible en nuestra consola de SCCM para que podamos tomarle inventario, hacer deploy de software, enviar configuraciones, etc. También podríamos haber hecho la instalación del primer equipo manualmente o bien utilizando el Client Push pero esto es para un deploy mas masivo, en este caso sería el primer equipo para pruebas.

Cuando esté instalado el cliente por GPO lo veremos dentro de las Queries según el sistema operativo que tenga. Hay que dar unos minutos para que aparezca ya que no es instantáneo. Una vez que tenemos todo el ambiente testeado y probado con los primeros clientes podemos configurar el Discovery tanto a través de Active Directory como de la red.

Un punto muy importante es instalar un antivirus en los servidores para no sufrir grandes dolores de cabeza. Pero esto puede traer otros dolores de cabeza incluso mas grandes a la hora de la performance de los servicios ofrecidos o bien incluso del funcionamiento de los mismos. Para esto es importante configurar exclusiones de ciertos procesos, directorios, archivos, extensiones, etc. De esa manera hacemos que el motor del antivirus no escanee ciertos puntos o aspectos importantes de la aplicación y que no afecte su performance o su funcionalidad.

Pero qué debemos excluir? Digo para no estar excluyendo cosas que sean realmente importantes para que escanee, cómo diferenciar qué es importante que no lo haga? Bueno algunas compañías nos recomiendan ciertas ubicaciones y acá hice una mini recopilación de algunos de esos puntos que deben ser tomados en cuenta y que recomiendo que las excluyan del antivirus. Las siguientes recomendaciones aplican para todo tipo de servicio, ya sea Exchange, SQL, Active Directory, DNS, etc. Podés aplicar una política de exclusión en el antivirus idéntica para todos los equipos y así te aseguras no tener ningún problema.

Directorios

%systemroot%\System32\Spool
%systemroot%\SoftwareDistribution\Datastore
%systemroot%\Sysvol
%systemroot%\system32\dhcp
%systemroot%\system32\dns
%systemroot%\ntds 
%systemroot%\ntfrs
%systemroot%\IIS Temporary Compressed Files
%systemroot%\system32\inetsrv
%systemroot%\Cluster
Q:\ (Unidad del Cluster Quorum)
M:\ (Unidad presente en Exchange)
*\Exchsrvr
%Program Files%\SharePoint Portal Server
%Program Files%\Common Files\Microsoft Shared\Web Storage System
*:\MSDEDatabases
%systemroot%\Temp\Frontpagetempdir
*\SMS\Inboxes
*\SMS_CCM\ServiceData
*:\Documents and Settings\All Users\Application Data\Microsoft\Microsoft Operations Manager
%Program Files%\Microsoft Operations Manager 2005
%Program Files%\Microsoft ISA Server\ISALogs
*:\MSSQL$WSUS
*:\WSUS
%Program Files%\Microsoft\Exchange Server
%Program Files%\Microsoft ForeFront Security
%Program Files%\Microsoft SQL Server
*:\MSSQL
%Program Files%\System Center Operations Manager 2007\

Extensiones

*.log
*.dit
*.mdf
*.ldf
*.ndf
*.edb
*.chk
*.stm
*.cab
*.jdb
*.config
*.dia
*.wsb
*.jrs
*.que
*.lzx
*.ci
*.dir
*.wid
*.000
*.001
*.002
*.cfg
*.grxml
*.lst
*.set
*.vdb
*.def
*.dat
*.wkf
*.pqf
*.pqf0
*.pqf1

Ejecutables o Procesos

Eseutil.exe
Lsass.exe
Cdb.exe
Cidaemon.exe
Store.exe
Emsmta.exe
Mad.exe
Mssearch.exe
Inetinfo.exe
W3wp.exe
Microsoft.Exchange.Search.Exsearch.exe
Microsoft.Exchange.Servicehost.exe
Msexchangeadtopologyservice.exe
Msexchangefds.exe
Dsamain.exe
Edgecredentialsvc.exe
Msexchangemailboxassistants.exe
Msexchangemailsubmission.exe
Edgetransport.exe
Msexchangetransport.exe
Galgrammargenerator.exe
Msexchangetransportlogsearch.exe
Msftefd.exe
Msftesql.exe
Microsoft.Exchange.Antispamupdatesvc.exe
Microsoft.Exchange.Contentfilter.Wrapper.exe
Oleconverter.exe
Microsoft.Exchange.Cluster.Replayservice.exe
Powershell.exe
Sesworker.exe
Microsoft.Exchange.Edgesyncsvc.exe
Microsoft.Exchange.Imap4.exe
Speechservice.exe
Microsoft.Exchange.Imap4service.exe
Microsoft.Exchange.Infoworker.Assistants.exe
Transcodingservice.exe
Umservice.exe
Microsoft.Exchange.Monitoring.exe
Umworkerprocess.exe
Microsoft.Exchange.Pop3.exe
Microsoft.Exchange.Pop3service.exe
Adonavsvc.exe
Fscstatsserv.exe
Fsccontroller.exe
Fscutility.exe
Fsctransportscanner.exe
Fscdiag.exe
Fsemailpickup.exe
Fscexec.exe
Fssaclient.exe
Fscimc.exe
Getenginefiles.exe
Fscmanualscanner.exe
Perfmonitorsetup.exe
Fscmonitor.exe
Scanenginetest.exe
Fscrealtimescanner.exe
Semsetup.exe
Fscstarter.exe
momhost.exe
monitoringhost.exe

Link | KB822158
Link | KB815263
Link | KB328841
Link | KB823166
Link | KB327453
Link | Manage Antivirus Software on Domain Controllers
Link | File-Level Antivirus Scanning on Exchange 2007
Link | Preventing Symantec AntiVirus Corporate Edition 9.x from scanning the Microsoft Exchange directory structure

Algunos gráficos fueron tomados de los standards de Microsoft, otros fueron agregados por mi dentro del paquete. Con este paquete de Stencils vas a poder generar todo tipo de gráficos sobre WSUS o cualquier plataforma de parches o seguridad. Creo que agregué todo tipo de gráficos pero si falta alguno puedes pedírmelo por acá o bien a través del foro para poder mejorar el paquete de Stencils.

Mas abajo dejo algunos ejemplos de qué tipo de gráficos se pueden generar con este grupo de Stencils. Igualmente esto se puede sumar a los que ya tenías por lo que puedes generar cualquier tipo de gráfico en Visio. No pude encontrar ningún paquete oficial de Microsoft sobre esto, así que generé el mio propio y lo comparto para todos aquellos que esten en la misma búsqueda.

El artículo está traducido al inglés mas abajo ya que puede haber gente interesada de cualquier parte del mundo, recordemos que este paquete es universal y los nombres de los objetos los puse en inglés para que cualquiera pudiera usarlos.

Fue probado tanto en Microsoft Visio 2003 como 2007, desconozco si funcionan bien en versiones anteriores del producto. Si lo probaste en una versión anterior y funcionó por favor comentalo así otros pueden aprovecharlo.

Descarga:
Note: There is a file embedded within this post, please visit this post to download the file.

ENGLISH

For some time I have the idea of grouping some Stencils and create other so we can generate charts on Microsoft Visio about WSUS, System Center Essentials, etc..

Some charts were taken from the Microsoft standards, others were added by my self inside the package. With this package of Stencils, you’re going to be able to generate any kind of graphics about WSUS or any other platform  about patching or security. I think I added all kind of graphics but if you find out that someone is missing please let me know here or through the forum in order to improve the Stensils package.

Below are some examples of what kind of graphics can be generated with this group of Stencils. This can be added to other Stencils that you already have so you can generate any kind of chart in Visio. I couldn’t find any official Microsoft package about this, so I make my own and want to share for all those who are in the same search.

The article is translated into English and Spanish as there may be people interested anywhere in the world, remember that this package is universal and the names of the objects are in English so that anyone can use them.

It was tested in Microsoft Visio 2003 as 2007, I don’t know whether they work well in previous versions of the product. If you tried in an earlier version and it worked well, please let me know so others can use it too.

Download:
Note: There is a file embedded within this post, please visit this post to download the file.

Algunos gráficos de ejemplo / Some graphic examples:

 

Recordemos que este pack fue compilado por mi y no es oficial por Microsoft. Cualquier tipo de soporte no podrá ser solicitado a Microsoft.

Remember, this pack was compiled by me and it is not oficial by Microsoft. Any kind of support can’t be requested to Microsoft.

Uno de los grandes temas del WSUS es el ancho de banda y el enlace disponible. Muchas veces tenemos sites remotos aplicando parches via WSUS y nos juega en contra ya que puede tomar gran parte del enlace para dicha tarea. Para este tema podemos implementar servidores réplica o downstream y que los equipos de dicho site se instalen los parches del servidor local.

Otra solución viable es configurar el servicio BITS (Background Intelligent Transfer Service). Este servicio es requerido por Windows Update y Microsoft Update y es quien controla el ancho de banda a utilizar o mejor dicho la bajada de los parches.

BITS 2.0 se puede bajar e instalar en Windows XP y Windows 2003 y BITS 3.0 es parte de Windows Vista y Windows Server 2008. Es posible cambiar los umbrales que utiliza BITS ya sea de subida o bajada a través de GPO. Esta configuración puede ser local utilizando gpedit.msc o bien desde una política de grupo en el dominio a través de la GPMC (gpmc.msc).

Ahí vamos a Computer Configuration » Administrative Templates » Network » Background Intelligent Transfer Service. Ahí vamos a encontrar dos ítems en 2003 y XP y varios mas Vista y 2008:

Maximum network bandwidth that BITS uses (en BITS 2.0)
Maximum network bandwidth for BITS background transfers (en BITS 3.0)
Timeout (days) for inactive jobs (en BITS 2.0)
Timeout for inactive BITS jobs (en BITS 3.0)

Las dos primeras (de las que verás solo una según tu versión de BITS) tratán sobre limitar el ancho de banda utilizado por BITS.

Primero debemos definir el transfer rate por segundo en kilobits. Por defecto está en 10, pero podemos adaptarlo a nuestro enlace. También debemos definir el horario en el que deberá limitar el ancho de banda y qué queremos que haga fuera de ese horario.

Esto es realmente muy útil para WSUS porque podremos limitar el ancho de banda al mínimo en horario de trabajo y fuera de ese horario podemos decirle que use todo lo disponible si es que así lo deseamos.
 
 
La otra política define cuantos días debe esperar para tomar un trabajo pendiente como abandonado. Esto significa por ejemplo, si comienza un trabajo de descarga y luego el equipo es apagado sin finalizarlo el trabajo queda pendiente.

Por defecto luego de 90 días de quedar pendiente se considera abandonado por el solicitante.

Si los equipos en nuestro ambiente tienden a quedar desconectados mucho tiempo tal vez convenga modificar este parámetro, de lo contrario con el valor por defecto alcanza.

Otra forma de optimizar el ancho de banda es utilizando Peer Caching. Este sistema está disponible para Windows Vista y Windows Server 2008 unicamente y que sean miembros de un dominio Active Directory.

Esta función que está disponible en BITS 3.0 permite que los equipos que bajen parches puedan compartirlos dentro de su misma subnet. Por ejemplo, cuando se baja un archivo BITS lo cachea y si tiene habilitado el peer caching comparte dicho archivo a los otros equipos de su misma subnet. Si al intentar bajar el archivo de ese equipo se demora o hay problemas entonces lo baja desde el WSUS o Windows Update como lo tenía programado antes. Para habilitar esta función vamos a Computer Configuration » Administrative Templates » Network » Background Intelligent Transfer Service, sólo en Windows Vista y Windows Server 2008.

Ahí tenemos que seleccionar la política Allow BITS Peercaching y configurarla como Enabled. Después tenemos que seleccionar Maximum network bandwith used for Peercaching y configurar el ancho de banda en bits por segundo para eso.
Otra política que tenemos que definir es Limit the BITS Peercache size con el porcentaje del disco a utilizar como caché. Y por último Limit age of items in the BITS Peercache con la cantidad de días que mantiene los archivos en la caché. El máximo para este ítem es 120 días.

Con estas configuraciones vas a poder limitar un poco mas el ancho de banda utilizado para la transferencia de archivos mediante BITS, un ejemplo es WSUS o Windows Update para los parches.

La herramienta de diagnóstico para los clientes de WSUS o mejor dicho para revisar las configuraciones y conexiones del servicio de Automatic Updates se llama WSUS Client Diagnostic Tool. Descargar »

Es un ejecutable llamado ClientDiag.exe que nos provee cierta información del cliente que nos ayudará a revisar si la conexión y configuración contra el WSUS Server o el módulo de Updates del System Center Essentials está ok. La misma fue diseñada para ayudar a los administradores a revisar el por qué un cliente no se está reportando en el WSUS o bien no está bajando actualizaciones.

El resultado que nos brinda la herramienta es a través de la línea de comandos y se asemeja al siguiente:

Checking for admin rights to run tool: Permisos para ejecutar esta herramienta
Automatic Updates Service is running: Si el servicio de Automatic Updates está corriendo.
Background Intelligent Transfer Service is running: Si el servicio BITS está corriendo.
Wuaueng.dll version 7.1.6001.65: Versión de la DLL de Automatic Updates. Esto es importante, si vemos problemas de actualización podemos probar actualizando la misma a la ultima versión.

Checking AU Settings: El tipo de configuración realizada sobre el equipo y si es por política o local. En mi caso “Notify Prior to Install”.

Checking for winhttp local machine Proxy settings: Si el proxy está activado o no, también si la conexión es directa al servidor.
Checking User IE Proxy settings: Las configuraciones existentes de Proxy en el equipo.

Checking Connection to WSUS/SUS Server: La configuración del WSUS Server. Qué parámetros tiene configurados el cliente. Si arroja errores de conectividad podemos revisar que tenga conexión al puerto 80 del servidor que figura en esta línea.
UseWuServer is enabled: Si el cliente está configurado para usar un servidor WSUS o no.
Connection to server: Si el equipo se pudo conectar al servidor que está previamente definido.
SelfUpdate folder is present: Si el directorio necesario para el Update local está creado o no.

Esto se complementa con los artículos anteriores que publiqué sobre configurar el cliente a través de GPO y del Registro de Windows. La idea es poder encontrar el problema si una PC no se reporta como corresponde o bien no actualiza los parches necesarios.

YouTube: http://www.youtube.com/
Soapbox: http://video.msn.com/
Jumpcut: http://www.jumpcut.com/
Metacafe: http://www.metacafe.com/

Luego de la instalación de System Center Essentials 2007 qué hacemos? Bueno, como primeros pasos deberíamos configurar los features del producto, luego configurar los equipos a administrar y por último configurar las opciones de Microsoft Update. Es vital realizar estas configuraciones para que el producto funcione correctamente y además para poder sacarle todo el jugo posible.

Configurar los Features del Producto

Luego de la instalación debemos hacer click en Required: Configure product features. Esto abrirá un asistente de configuración que debemos seguir para poder configurar el producto. La primer pantalla es la introducción de lo que vamos a hacer. Podemos marcar la opción para que no vuelva a mostrarnos esta ventana. Luego, la segunda pantalla es la configuración de la salida a internet a través de un Servidor Proxy. Ahí deberemos configurar los parámetros del Proxy en caso de tenerlo.

La siguiente pantalla sirve para configurar la GPO de dominio automáticamente o bien crearla luego nosotros manualmente. Esta GPO sirve para decirle a las PCs que los updates los tome de nuestro servidor de SCE. Si decimos que si debemos estar logueados con una cuenta de Domain Admin. La siguiente pantalla nos pregunta sobre las excepciones del Firewall. Recomiendo decir que si para que configure estas excepciones de lo contrario no se podrán instalar agentes en los equipos si tienen el Firewall iniciado.

 
Luego va a preguntarnos sobre la configuración de Remote Assistance. SCE puede habilitar en los equipos administrados el Remote Assitance. Si no lo vamos a usar podemos decirle que no. En la siguiente pantalla del asistente nos consulta si queremos que colecte los errores de aplicación de las PC’s que administramos. El directorio al que enviemos los errores debe estar sobre NTFS y con al menos 2Gb libres sin mencionar que la carpeta ya debe existir.

El siguiente paso nos preguntará si queremos enviar los errores recolectados a Microsoft. Esto es parte de la Error Reporting Tool que ya existe en los equipos, pero queremos reenviar todo a Microsoft? Esto es lo que debemos definir en esta ventana. Puede ser tanto básico como detallado el reporte que se envía. Luego si queremos recibir un correo con el reporte diario de estado del ambiente debemos configurar los parámetros que nos pide.

Ahora viene un punto crítico que es si queremos que descubra automáticamente todos los equipos de nuestro ambiente o lo vamos a hacer manualmente. Yo personalmente prefiero hacerlo mas manual para tener un poco de control sobre el tema. Una vez descubierto el ambiente si se puede definir que sea automático para las actualizaciones del mismo. Por último veremos como configura todo lo que acabamos de definir.

Una vez finalizado hacemos click en Close y este punto ya estaría terminado.

Configurar Equipos y Dispositivos a Administrar

Para este paso es necesario hacer click en Required: Configure computers and devices to manage. Nuevamente abrirá un asistente que nos guiará en la configuración de los equipos y dispositivos. En la primer pantalla veremos la típica introducción de lo que haremos. Luego tenemos la opción de un Discovery o Descubrimiento automático o Avanzando. El automático es sobre el dominio del mismo servidor y traerá todos los equipos basados en Windows. El Avanzado podemos seleccionar si queres solo clientes, solo servers, dispositivos de red, etc. Si elegimos Avanzado tendremos un paso mas en el asistente para seleccionar el método, de lo contrario pasa directamente a la autenticación.

La pantalla del método de Discovery nos deja elegir entre Active Directory o bien seleccionar el equipo manualmente o tipearlo. Luego debemos definir las credenciales que utilizaremos en el Descubrimiento de los equipos. Puede ser la misma del SCE o bien una específica.

El proceso de Discovery se iniciará y encontrará los equipos que nosotros especificamos, ya sea por AD o bien manualmente. De lo encontrado debemos seleccionar los equipos que necesitemos administrar.

Ahora si, el típico resumen que nos dirá cuántos agentes requiere instalar y una vez que hagamos click en Finish inciará una ventana con la instalación de los mismos. Ahí podremos ver un status de cómo termina la instalación y tomar acciones donde sea necesario. Esta ventana podemos cerrarla que la instalación seguirá en background. Igualmente si es el primer equipo para probar la implementación de SCE sugiero esperar a ver cómo resulta, luego el deploy masivo si podremos ejecutarlo en background.

Configurar Opciones de Microsoft Update

Por último nos queda configurar las opciones de Microsoft Update que para esto debemos hacer click en Required: Configure Microsoft Update settings. Recordemos que SCE 2007 incluye un módulo de instalación de parches sobre los equipos como WSUS así que este punto es muy importante. Comenzamos con la introducción de los asistentes y luego con la configuración del Servidor Proxy, aunque si ya lo configuramos en el punto anterior nos traerá la misma información.

El siguiente punto deberemos Sincronizar en vez de hacer Siguiente. Esto es muy parecido al asistente o Wizard del WSUS. Si leíste los artículos sobre configuración del WSUS o configuraste alguno vas a ver que es muy similar ya que es la configuración de dicho módulo. Una vez que finaliza seleccionaremos los productos que vamos a actualizar en los equipos que administremos.

Siguiendo nos queda elegir los idiomas que vamos a soportar. Acá debemos seleccionar todos los idiomas que pueda existir en nuestro ambiente para que todos los equipos estén actualizados. Luego la clasificación, son los tipos de actualizaciones que otorgaremos. Entre ellas se encuentran, Parches Críticos, Service Packs, Updates, Aplicaciones, etc. 

Luego podemos definir una política de aprobación automática para ciertos parches o bien manejar todos manualmente. Sugiero seleccionar Definition Updates en forma automática ya que es la actualización del Windows Defender. Seguimos y configuramos el horario en el que queremos que sincronice contra internet para bajar los parches. Casi siempre se selecciona en la madrugada, pero cada cliente tiene diferentes necesidades.

El resumen típico y la posibilidad de iniciar la sincronización al cerrar el asistente. Si es horario productivo no lo recomiendo ya que es el que mas demora.

Al finalizar este Wizard damos por terminada la configuración inicial de SCE 2007 y podremos empezar a administrar los equipos que seleccionamos en el Discovery. Recomiendo iniciar probando con algunos equipos con diferentes versiones de OS y luego cuando sabemos que está todo ok con las imágenes de la empresa, ahí si hacer el deploy masivo.

En artículos siguientes comentaré la forma de hacer un deploy de Software a los equipos, si te interesa Suscribite!!

System Center Essentials 2007 es una herramienta de administración desarrollada por Microsoft para ayudar al personal de IT con sus tareas diarias desde una simple y única consola. Podemos segurizar, actualizar, monitorear y darle seguimiento a nuestro ambiente de IT. A eso hay que sumarle todos los reportes que podemos obtener de dicha aplicación.

En este artículo pretendo comentar los pasos necesarios para la instalación del producto. Igualmente antes de comenzar habría que revisar si el equipo cuenta con los requisitos mínimos, determinar la base de datos si va a estar localmente o en otro equipo, las cuentas de usuario, etc.

Los requisitos mínimos en cuanto a software son:

• Microsoft Windows Server 2003 x86 SP1 o superior  (No soporta CPU’s IA64)
• IIS 6 o superior habilitado
• BITS 2.0 habilitado
• ASP.NET habilitado en el IIS
• Active Directory debe estar disponible en el ambiente
• SQL Server 2005 Express SP1 o superior  (No soporta SQL 2005 Mirroring)
• No soporta Clustering
• .NET Framework 3.0  Download »
• SNMP habilitado (no es un requerimiento pero se va a utilizar)
• MSXML 6.0 (si no está instalado el mismo setup lo hace)

Ahora ejecutamos setup.exe y seguimos los pasos de instalación.
La primer pantalla debemos seleccionar lo que queremos instalar. En este caso seleccionamos “Full Setup” para instalar el servidor completo. Cabe destacar que la “Installation Guide” es una guía completa en formato de Windows Help que nos puede ayudar en muchos aspectos en la configuración del producto. Luego veremos la primer pantalla de bienvenida de la instalación.

Al hacer click en Next o Siguiente va a chequear los prerequisitos de la aplicación para ver si necesitamos instalar algo mas o podemos continuar con el setup.

Veremos que el chequeo de memoria tiene un Warning porque no tengo 2Gb de Memoria como es el recomendado por Microsoft, pero igual podemos continuar. Si tenemos dudas con respecto a algún ítem podemos hacer click en el botón “More”. Luego veremos la pantalla de la licencias de Microsoft que siempre aceptamos :P. Debemos introducir el nombre y compañía según nuestra licencia… Esas ventanas las salteamos para no hacer muy largo el post ya que no hay que configurar nada.

Ahora si vienen dos secciones importantes. La primera es si queremos almacenar los parches localmente o bien que los obtengan desde Microsoft Update. Es el mismo tipo de configuración que para WSUS. Es importante que para pasar a la siguiente ventana debemos tener 12Gb libres como mínimo en la unidad que seleccionemos. Luego nos permite seleccionar el tipo de base de datos que tendremos. Podemos apuntarlo a un servidor de SQL local o externo (recomendado para grandes ambientes) o bien dejar que instale un SQL 2005 Express localmente. 

Luego configuramos una cuenta que tenga permisos de Administrador sobre los equipos que vamos a administrar. Posterior a eso definimos si queremos enviar datos a Microsoft sobre nuestra implementación, el típico Customer Experience.

Como último paso tenemos un resumen de lo que vamos a hacer, osea la instalación y si queremos visitar el sitio de Microsoft para verificar que tenemos todos los parches instalados y el equipo al día.  Una vez que finaliza la instalación y abrimos por primera vez la consola veremos la pantalla que se adjunta a continuación. Este es el Inicio de System Center Essentials (SCE). La instalación puede demorar unos minutos si debe instalar el SQL Express.

Qué hay que configurar ahora? Esta sería la pregunta de toda persona que termina de instalarlo. Bueno si bien voy a ir preparando otros artículos relacionados podríamos empezar con:

• Conocer la Consola de Administración
• Monitoreo
• Administración
• Management Packs
• Agregar Equipos
• Software Deployment
• Inventario
• etc…

No lo sigo en este mismo artículo ya que sino se hace muy extenso, pero prometo ir haciendo mas artículos relacionados al igual que con WSUS.

Link | System Center Essentials 2007
Link | System Center Essentials 2007 Service Pack 1

En un artículo anterior comentamos cómo configurar los clientes de WSUS por GPO, pero para poder hacerlo hace falta un dominio. Qué pasa cuando no tenemos un dominio donde podamos enviar políticas a los clientes? Debemos si o si configurar políticas locales o como mejor solución, hacerlo por el Registro de Windows (Registry).

La forma de usar las políticas locales del equipo es idéntico a configurarlo por GPO sólo que en vez de editar la política de dominio abrís el Local Policy Editor y modificas la política global.

La otra opción es generar un archivo .reg con todos los parámetros y distribuirlo en las PC’s ya sea manualmente o bien con alguna aplicación de deployment que se tenga implementado. A continuación comento las entradas en el registro de Windows involucradas en la configuración del WSUS.

Las opciones relacionadas con el servidor de WSUS se encuentran en:

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

Una vez dentro de esta ruta podremos configurar los siguientes parámetros:

Las opciones relacionadas con el servicio Automatic Updates se encuentran en:

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

Una vez dentro de esta ruta podremos configurar los siguientes parámetros:

Se puede armar un gran archivo con extensión .reg y distribuir con el sistema o aplicación que mas prefieras. En mi caso prefiero usar GPO, pero si no tenes un dominio o queres configurar algo manualmente, estas son las entradas en el registro de Windows que participan en la configuración del AU.

En artículos anteriores hemos cubierto la instalación de un Servidor de WSUS como también tomar Backup del mismo. Asimismo cubrimos la parte de Restore y el pasaje de la data a un nuevo hardware. Ahora todavía no hemos configurado via GPO los clientes para que se reporten en el servidor de WSUS. Ese es el objetivo de este artículo.

Los clientes de WSUS requieren tener una versión de Automatic Updates (AU) actualizada. En la instalación del WSUS se publica automáticamente la última versión cliente de AU para que se instale en los equipos y así asegurar el correcto deploy de los parches y actualizaciones. En este caso vamos a cubrir la configuración de los clientes via GPO, eso quiere decir que en el ambiente existe un Active Directory. Si este no es tu caso, próximamente comentaré las entradas del registro necesarias para poder hacer una configuración manual. Sino podés usar la política local de cada equipo, pero en el caso manual es mas práctico enviar un .reg a los equipos.

1. Primero debemos crear una nueva política (GPO) así no utilizamos otra que tenga otro fin. La podemos llamar “WSUS PC Clientes” y abrimos el editor de la política.

2. Una vez que abre el editor tal vez nos encontremos con que las opciones de Automatic Updates no están disponibles. Si este es tu caso es porque no está agregado el template wuau.adm dentro de la GPO.
Para agregar dicho template:

• Hacemos click derecho sobre Administrative Templates
• Seleccionamos Add/Remove Templates y luego hacemos click en Add
• Ahí buscamos el archivo wuau.adm dentro de Windows\inf y hacemos click en Open
• Por último cerramos la ventana haciendo click en Close

  

Ahora ya deberíamos tener las opciones de Automatic Updates agregadas. Si no estas seguro si están o no podes seguir esos pasos para verificar que el archivo wuau.adm esté cargado.

Si el template está cargado significa que ya podemos empezar a configurar la política para luego aplicarla a los clientes.

3. Dentro del editor de GPO nos vamos hasta Administrative Templates » Windows Components » Windows Update. Ahí vamos a ver una serie de políticas que podemos configurar.

Si queremos habilitar que el cliente se comunique con el servidor basta con configurar 2 de todas esas opciones. El resto complementa todo lo que se puede configurar en un cliente.

Confiure Automatic Updates: Esta opción es la principal que le dice al servicio cliente que debe activarse y buscar actualizaciones. Aquí podemos configurar para que notifique al usuario, para que instale, para que el Admin local decida, etc. Este punto cada uno lo configura según lo que su empresa o ambiente necesite.

Es importante si decidimos instalar los parches en los clientes automáticamente, que los usuarios estén notificados que esto puede pasar, de lo contrario tal vez recibas llamadas a la Mesa de Ayuda sobre esto.
 
 
 
Specify intranet Microsoft update service location: Este es el segundo ítem que se debe configurar para habilitar a un cliente a que se conecte contra el WSUS Server. Simplemente declaramos cuál es el servidor de WSUS que va a atender en esta política. Lo importante es que figure en ambos campos de la misma manera y la estructura es http://nombrewsusserver.

Luego de configurar este parámetro y asignar la política los clientes ya deberían empezar a aparecer en la consola de WSUS bajo no asignadas o Unassigned Computers.

Ahora bien, el hecho de que figuren en el grupo de Computadores No Asignadas es porque todavía no creamos ningún grupo en el WSUS y porque todavía no definimos si vamos a mover las PC’s manualmente o bien que la misma GPO las acomode donde corresponden.

Vamos a hacer las cosas como corresponden y primero creamos un grupo dentro de la consola de WSUS.

4. Dentro de la consola de WSUS hacemos click derecho sobre “All Computers” y ahí elegimos “Add Computer Group”.

El nombre que elegimos para el grupo es importante y debemos recordarlo ya que luego deberemos configurarlo en la GPO si es que dicidimos hacer que la misma GPO acomode los equipos.

5. Para que la GPO pueda acomodar los equipos automáticamente todavía falta configurar algo en el WSUS Server. Para esto vamos a “Options” y ahí hacemos click sobre “Computers”. Nos va a aparecer una ventana con una opción de si queremos usar la consola de WSUS para mover las PCs o bien usar Group Policy Object (GPO).

En nuestro caso vamos a seleccionar “Use Group Policy or registry settings on computers”.

Con este ítem nos aseguramos que la GPO va a acomodar automáticamente las PCs en el grupo que creamos.

 
6. Para concretar esta configuración sólo falta configurar un ítem en la política que estábamos creando. Volvemos al editor de GPO y buscamos “Enable client-side targeting”.

Habilitamos este ítem y ponemos el mismo nombre de grupo que definimos en el WSUS. En mi caso el nombre del grupo es “Finanzas” ya que representa un área en la empresa que tal vez requiera otro horario de instalación de parches al de IT por ejemplo.

Un punto importante es que necesitas una política o GPO por grupo de WSUS que quieras asignar.

7. Cerramos el editor de GPO, la asignamos a alguna OU y listo, las PCs ya se deberían reportar en el WSUS por lo que sólo faltaría aprobar los parches que querramos. Cabe destacar que configuramos lo mínimo y necesario pero en la GPO hay muchas otras opciones como por ejemplo:

Reschedule Automatic Updates scheduled installations: Es el tiempo que el cliente espera luego del Startup para procesar las instalaciones programadas.
No auto-restart for scheduled Automatic Update installation options: Espera a que el sistema sea reiniciado para completar una instalación programada en vez de reiniciarlo automáticamente.
Automatic Update detection frequency: Es el número total de horas que el cliente va a esperar para chequear el servidor de WSUS por actualizaciones.
Allow Automatic Update immediate installation: Define que si el update no requiere reiniciar el equipo ni algún servicio entonces que lo instale inmediatamente.
Delay restart for scheduled installations: El tiempo que espera el cliente para reiniciar luego de un reinicio programado.
Reprompt for restart with scheduled installations: El tiempo que el cliente espera para preguntar por un reinicio programado.
Allow non-administrators to receive update notifications: Declara si los usuarios que no son administradores pueden recibir notificaciones de updates o no.
Allow signed content from the intranet Microsoft update service location: Habilitamos que se distribuyan updates de terceros, sino es sólamente de Microsoft.
Remove links and access to Windows Update: Los usuarios que tengan aplicado esto no podrán acceder al sitio de Windows Update.
Disable access to Windows Update: Deshabilita el acceso a las funciones de Windows Update de la máquina para que sólo se utilice a través del WSUS.
Do not display ‘Install Updates and Shut Down’ option in Shut Down Windows dialog box: Habilita o deshabilita la opción de instalar los parches y apagar el equipo en el menú de Apagar del cliente.
Do not adjust default option to ‘Install Updates and Shut Down’ in Shut Down Windows dialog box: Si queremos que por defecto sea la opción elegida cuando apagamos el cliente.

Este parece ser un problema mas que común en las instalaciones de WSUS. La mayoría de los usuarios se quejan porque dicen que a veces los clientes dejan de reportarse o de detectar o arrojan errores de Automatic Updates (AU) al revisar los logs. Si bien tenemos comandos para poder forzar la detección como por ejemplo wuauclt.exe /detectnow muchas veces este no funciona ya que alguna DLL de AU se corrompió o dejó de responder como debía.

Cómo podemos resolver estos problemas desde el cliente? Simple, podemos ejecutar una serie de comandos para poner el cliente de AU en cero y que vuelva a registrarse en la consola, previamente registrando las DLL nuevamente en el sistema operativo. Si esto no resuelve tu problema del cliente por favor dejame un comentario y abrí un tema en el foro para poder darle mayor seguimiento. Igualmente algunos pasos son manuales, pero siempre simples.

Son varias etapas, algunas manuales y otras por script. Podemos ejecutar línea por línea en una ventana de MS-DOS o bien podemos copiar todas las líneas y pegarlas en un Notepad. Luego guardarlo como un archivo .bat o .cmd y al ejecutarlo ejecutará todas las líneas en órden. Estas líneas funcionan para resetear el Automatic Updates, así que si tenes problemas con el sitio de Windows Update también puede servirte. Previamente a esto recomiendo cerrar cualquier ventana de Internet Explorer que se tenga abierta en el equipo.

PASO1: Ejecutar líneas o bien como archivo .bat o .cmd

net stop bits
net stop wuauserv

REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\Wi ndowsUpdate\Auto Update" /v LastWaitTimeout /f
REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\Wi ndowsUpdate\Auto Update" /v DetectionStartTime /f
REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\Wi ndowsUpdate\Auto Update" /v NextDetectionTime /f

regsvr32 /s wuapi.dll
regsvr32 /s wuaueng.dll
regsvr32 /s wuaueng1.dll
regsvr32 /s wucltui.dll
regsvr32 /s wups.dll
regsvr32 /s wuweb.dll
regsvr32 /s jscript.dll
regsvr32 /s alt.dll
regsvr32 /s msxml3.dll
regsvr32 /s softpub.dll
regsvr32 /s wups2.dll
regsvr32 /s Initpki.dll
regsvr32 /s Mssip32.dll

PASO2: Realizar las siguientes tareas manualmente

1. Borrar de todas las particiones que se encuentre la carpeta "WUTemp"
2. Borrar la carpeta "Catroot2" generalmente en Windows\System32
3. Borrar la carpeta "WindowsUpdate" que se encuentra en Program Files. Ojo porque es una carpeta oculta.
4. Dentro de las propiedades del Internet Explorer, en Opciones Avanzadas se debe habilitar "Use HTTP 1.1 through proxy connections"
5. Borrar la carpeta "SoftwareDistribution" del directorio Windows y de Windows\System32
6. Elimina el contenido Offline del Internet Explorer desde IE Tools/Options y ahí hacer click en "Delete"

PASO3: Reiniciar el equipo

Al reiniciar el equipo se va a iniciar nuevamente los servicios de Automatic Updates y BITS (Background Intelligent Transfer Service) que paramos en el primer paso. Si no es posible reiniciar ya que estas trabajando sobre un servidor o por otra razón entonces debes iniciar dichos servicios. Los comandos para hacerlo son:

net start wuauserv

net start bits

Luego sólo nos quedaría forzar la detección en el WSUS Server. Para esto podemos utilizar el comando wuauclt.exe /resetauthorization /detectnow

Ese comando es para forzarlo en WSUS, si seguiste estos pasos porque no te funcionaba el Automatic Updates o Windows Update tenes que volver a ingresar y hacer un chequeo a mano. Te va a pedir instalar el cliente nuevamente y luego funcionará automáticamente sin problemas.

Te recomiendo mirar igualmente el archivo WindowsUpdate.log para ver si siguen los errores. En caso de que sigan contactame a través del foro abriendo un tema por tu caso.

Si es posible. Gracias a un artículo en el Blog de Daniel Matey encuentro la posibilidad de utilizar PowerShell para obtener información, cambiar datos y trabajar con el WSUS. En su artículo comenta la posibilidad de utilizar este gran sistema de automatización llamado PowerShell (he comentado sobre esto antes en este sitio, mas que nada en la parte de Exchange 2007) para poder hacer tareas en el WSUS.

Link | Un vistazo rápido a WSUS 3.0 y PowerShell

En el post explica cómo conectar PowerShell con el API de WSUS 3.0 para luego obtener o modificar la información que querramos.

Lo bueno de PowerShell es que podemos automatizar el script, así que todo lo que nos permita hacer PowerShell será programable y podremos ahorrar muchísimo tiempo de administración. Algunas de las tareas que nos dejará ejecutar:

CancelAllDownloads
ExportUpdates
GetCleanupManager
GetComputerStatus 
GetConfiguration
GetDatabaseConfiguration
GetInventory
[...]

Ahora que sabemos como conectar PowerShell y WSUS en breve voy a publicar algunos scripts que ayuden a automatizar las tareas diarias. Te propongo que te suscribas desde la barra de la derecha para poder tener los artículos al día en tu correo o lector de noticias favorito.

La idea de armar este artículo surge porque he visto en varias comunidades que la gente sigue preguntando cómo realizarlo. Las razones pueden ser variadas, la mayoría porque el equipo le queda chico y quiere cambiar el hardware o bien porque el equipo anterior murió y tienen que instalarlo en uno nuevo.

El procedimiento no es muy complicado ni difícil, igualmente en este caso lo voy a comentar con la base de datos que se instala en el asistente inicial. Si optaste por instalarlo en un SQL Server 2005 en el mismo equipo varía la parte de recuperación de la base de datos. Ahora si optaste por apuntar la base a otro SQL Server entonces sólo es necesario reestablecer esa conexión en el nuevo equipo.

Para no seguir mareandote con palabras sin llegar a nada, vamos a pasar a la parte técnica de cómo realizarlo. Primero te comento el ambiente que tengo en el laboratorio para que estes mas en tema:

Servidor 1: 2K3SU01 - Actual WSUS - Futuro muerto jaja
Servidor 2: 2K3SU02 - Futuro WSUS
Base de Datos: Windows Internal Database
Ambos equipos están virtualizados con Microsoft Virtual Server 2005 R2 SP1. Hay 1600 parches en la base de datos con diferentes aprobaciones y un Servidor reportado como cliente (3KTITO). Veremos si esta información se mantiene en el nuevo equipo cuando lo migremos.

1. Revisemos el status inicial del servidor de WSUS actual. Esto nos va a servir para comparar la información origen con la destino y ver si la migración resultó ok. Si el equipo ya murió seguir con los pasos de mas adelante. Este es para una migración planificada.
 
2. Un paso interesante si tenemos el equipo todavía activo es realizar una limpieza de la base de datos para no migrar basura. Esto lo hacemos desde Options » Server Cleanup Wizard. Ahí podemos limpiar un poco la base de parches que no necesitamos, equipos que ya no se reportan, etc. Digamos que sería un paso previo a revisar el status del servidor, pero es un paso optativo.

3. Realizamos un backup completo del WSUS con ntbackup. Si no sabes como hacerlo o queres los pasos te recomiendo que leas el siguiente artículo Cómo hacer un Backup del WSUS [ Tutorial ]

4. Una vez que tenemos el backup del equipo y la info correspondiente, podemos apagar el equipo original. Si el equipo estaba muerto debemos contar con un backup para poder instalarlo en un equipo nuevo sino deberá instalarse desde cero, bajar los parches y las PC's deberán reportarse nuevamente.

5. Bueno, ya tenemos el equipo nuevo arriba, con el backup del 01 copiado y los archivos de instalación del WSUS listos para usarse. Por qué necesitamos los archivos de instalación? Porque la idea es reinstalar el WSUS y recuperar las configuraciones y base de datos.

Lo que si vamos hacer es renombrar el servidor para que tenga el mismo nombre que el anterior así no debemos modificar políticas de WSUS. Esto lo hacemos desde My Computer » Properties » Computer Name » Change.

6. Una vez renombrado el servidor debemos asegurarnos de tener todos los prerequisitos de WSUS instalados y luego iniciar la instalación de la misma forma que estaba instalado en el equipo anterior. Si no sabes como instalarlo o no estas seguro de los pasos te recomiendo que leas Instalando WSUS 3.0 Paso a Paso [ Tutorial ]
Lo instalamos con la misma ruta que el equipo anterior. Si queremos cambiar la ubicación de la base de datos podemos hacerlo luego, ahora recomiendo para levantar el equipo mantener la misma ruta.

7. Una vez instalado, garantizamos que funcione bien. En cuanto lo vemos funcionando comenzamos con el restore de información para poder dejarlo igual a como estaba antes. Si tenes dudas de cómo realizar el Restore te recomiendo que revises el artículo comentado en el punto 3 donde hicimos el backup. Debemos hacer el restore en la misma ruta que fue tomado el backup. De esta manera garantizamos que los datos se pisaran con los que tenemos en nuestro backup. Debemos parar todos los servicios relacionados a WSUS antes de realizar dicho Restore para garantizar que pueda sobreescribir cualquier archivo.

8. Si seguimos todos los pasos vamos a tener el WSUS levantado en un nuevo equipo con toda la info migrada y funcionando. Ahora bien, si apuntas a un SQL 2005 externo podes directamente apuntar a dicha base y luego hacer restore de los parches y directorios. Si queremos cambiar la ruta de los directorios de instalación de WSUS o bien de los parches para enviarlos a otra unidad, te recomiendo que sigas leyendo el Blog para el próximo artículo de WSUS.  :)

A veces puede pasar que al querer remover la instalación de WSUS nos arroje algún error y no termine removiendo parte de la misma. La idea es comentar los pasos necesarios para remover dicha instalación manualmente. Qué se puede borrar, qué hay que modificar, qué hay que ejecutar, etc.

Algunos pasos estan basados en KB's de Microsoft que también linkeo en el mismo artículo. Luego de removerlo podrás instalarlo en el equipo nuevamente como si nunca hubiera estado instalado.

1. En principio debemos parar todos los servicios de WSUS asociados. Tanto de Update Services, como de la base de datos en caso de ser local y los de IIS para poder hacer una desinstalación completa y que no falle ningún archivo.

2. En caso de ser un equipo dedicado a WSUS habría que eliminar la base de datos. Si se instaló con SQL Server 2005 no hace falta desinstalarlo, sólo remover la base, pero si se utilizó Windows Internal Database habría que removerla para que no arroje errores al reinstalarlo.

• Abrir una ventana de comandos (cmd.exe)
• Ejecutar uno de los siguientes comandos:
  En plataforma 32-bit: msiexec /x {CEB5780F-1A70-44A9-850F-DE6C4F6AA8FB} callerid=ocsetup.exe
  En plataforma 64bit: msiexec /x {BDD79957-5801-4A2D-B09E-852E7FA64D01} callerid=ocsetup.exe
• Eliminar las bases que se encuentren debajo de la carpeta %windir%\SYSMSI\SSEE

Link de Microsoft »

3. Ahora procedemos a eliminar el directorio de instalación, generalmente en           %ProgramFiles%\Update Services. Borramos esa carpeta y todas las subcarpetas.

4. Eliminamos la entrada en el registro correspondiente a la instalación del producto:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services

5. Ahora eliminamos el resto de las entradas del registro que corresponden a los servicios de WSUS:

HKLM\SYSTEM\CurrentControlSet\Services\WSUS: API Remoting Web Service
HKLM\SYSTEM\CurrentControlSet\Services\WSUS: Client Web Service
HKLM\SYSTEM\CurrentControlSet\Services\WSUS: Client Web Service Methods
HKLM\SYSTEM\CurrentControlSet\Services\WSUS: Reporting Web Service
HKLM\SYSTEM\CurrentControlSet\Services\WSUS: Server Web Methods
HKLM\SYSTEM\CurrentControlSet\Services\WSUS: Server Web Service
HKLM\SYSTEM\CurrentControlSet\Services\WSUS: Update Regulation Web Methods
HKLM\SYSTEM\CurrentControlSet\Services\WSusCertServer
HKLM\SYSTEM\CurrentControlSet\Services\WsusService

6. Como siguiente paso debemos eliminar los archivos de instalación MSI del producto. Para esto vamos a utilizar una herramienta de Microsoft llamada Windows Installer CleanUp Utility. La utilidad se encuentra en el KB290301 » de Microsoft. Ahí figura como bajarla y ejecutarla. Sólo debemos seleccionar los paquetes correspondientes a WSUS y removerlos.

7. Si el equipo no tiene otro sitio web instalado, entonces te recomiendo remover el servicio de IIS del servidor utilizando Add/Remove Programs o bien Roles del 2008. En caso de que existan otros sitios sólo podes eliminar el de WSUS junto a su Application Pool correspondiente. En caso de que compartan el sitio pero con otros directorios virtuales, podes eliminar los siguientes que sí estan relacionados con WSUS:

• Inventory
• DSSAuthWebService
• ApiRemoting30
• Content
• ReportingWebService
• SelfUpdate
• ServerSyncWebService
• SimpleAuthWebService
• ClientWebService

8. En caso de que no vayas a reinstalar el WSUS o bien quieras que baje todos los parches nuevamente y regenere la base de datos de información, tenés que eliminar el directorio C:\WSUS. La unidad varía según cada instalación. Si vas a reinstalar el producto y queres mantener lo mismo, podes dejarlo y apuntar al mismo directorio, pero recomiendo remover todo y empezar de nuevo.

9. Ahora reiniciá el servidor y ya quedaría limpio para reinstalar.

10. Recordá que si eliminaste el IIS y querés reinstalar tenes que volver a agregarlo con los componentes básicos como requisito de instalación.

La idea es comentar las diferentes formas de hacer un correcto deployment de Windows XP Service Pack 3 en el ambiente. Si tienes un solo equipo es fácil, puedes hacer Windows Update y listo, pero cuando tienes que administrar un ambiente mucho mas grande debes pensar en las diferentes formas de hacerlo para no afectar anchos de banda, aplicaciones, cortes de servicio, etc.

Las opciones que tenemos para hacer el deploy se extienden desde Manual (equipo por equipo), por política de dominio (GPO), por script de inicio o asignado por GPO hasta realizarlo desde aplicaciones como WSUS o System Center Essentials.

La opción de armar un script de instalación remota o bien por política requiere que tengamos el Service Pack bajado y copiado a una ruta accesible en la red de nuestro ambiente. Ahí podemos asignar el Service Pack o bien publicar el mismo para que los usuarios lo instalen al elegirlo. Recomiendo "asignarlo" a los equipos para así asegurarte que se instalen en los mismos. El problema de aplicarlo por GPO es que el control lo tenemos en base a nuestra estructura de OU y cuentas de PCs. Tampoco tenemos forma de controlar cuantas llevamos instaladas y cuantas no, etc.

Si bien el reporting se podría hacer con WSUS y aplicarlo por GPO, también podríamos aplicarlo y hacer el reporting via WSUS. WSUS 3.0 SP1 ya tiene disponible el Windows XP SP3 para su deployment. Solo debes seleccionarlo y aprobarlo para los grupos de PCs que tengas creado. Eso si, tené en cuenta los enlaces ya que es un update bastante grande y podría saturar los mismos.

Otra opción es utilizar ambos modelos, ya sea WSUS para los sites con un buen ancho de banda y GPO para los sites con un enlace algo pobre, ya que si tenemos un DC en ese site podemos usarlo como server para deployment. Obviamente que si tenemos un servidor de WSUS en ese site se puede usar para el deploy, pero considerando que no haya, tal vez un DC si.

Antes de ejecutar el plan de deployment que hayas armado y decidido, ten en cuenta que debes hacer un laboratorio con todos los tipos de PC que tengas en el ambiente para ver cómo afecta a los mismos. Prueba el SP3 con las aplicaciones de tu ambiente también. Esto te va a garantizar un update de lo mas tranquilo con los usuarios y tener el ambiente al día. Por último, luego del deployment, recuerda actualizar la imagen de instalación de tus equipos para que ya salgan con SP3 incluído.

Link | Windows XP SP3 Network Installation Package for IT Professionals - 316Mb
Link | Windows XP Service Pack 3 - ISO-9660 CD Image File - 545Mb
Link | Windows XP Professional Technet Home

Qué es el Extension Pack para WSUS 3.0 de EminentWare? Es una herramienta desarrollada por la empresa para poder extender las funciones del WSUS y llevarlo a un nivel aún mas avanzado. Agrega no sólo funciones, sino flexibilidad, administración, capacidad, etc. WSUS es una herramienta de Microsoft muy útil a la hora de actualizar nuestra infraestructura, pero tal vez le falte algunas funciones. Los requisitos mínimos son los mismos que para el WSUS y no requiere nada extra, sólo extiende tu estructura de WSUS actual, lo que provee bajos costos de implementación. Entre algunas de sus funciones se puede destacar:

• Administración de los Updates mas avanzada
• Templates de políticas para la distribución de los parches
• Distribución de parches de MS como de terceros
• Vistas en tiempo real
• Administración de los clientes avanzada
• Delegación de la aprobación de parches
• Descubrimiento de la red hasta por IP
• Inventario avanzado del ambiente
• Reportes avanzados de la plataforma
• Apagado, Reinicio y Wake-on-Lan
• Programar limpieza de la base de datos
• Identificación de equipos que no se reporten en la consola
• Forzar la aplicación de los parches

Los costos no son elevados para mejorar el ambiente de parchado de la infraestructura, así que esta es una opción válida para optimizar tu implementación de WSUS. Además ofrecen una versión de 30 días de prueba para que revises todos los features de este excelente pack.

Link | EminentWare
DataSheet | EW_Extension_Pack_DS_5.PDF

La administración de los updates o parches es muy importante para un ambiente. Ya sea para PCs como para servidores de un datacenter. El tener el ambiente actualizado a la fecha hace que baje mucho las probabilidades de tener un ataque o infección en los equipos. Por ejemplo, los bloggers actualizan WordPress para no sufrir daños o robos de la base de datos. En los equipos pasa lo mismo pero a otro nivel.

La estructura Microsoft presenta diferentes formas de realizar dichas actualizaciones para mantener la seguridad del ambiente. Estas opciones se pueden clasificar en usuarios comunes, pequeña o mediana empresa y una gran compañía.

A nivel de usuario doméstico estamos acostumbrados a actualizar nuestro Windows a través del Microsoft Update. En Windows Vista ya no abre mas el sitio de actualizaciones sino que nos abre la herramienta para actualizar Windows Update.
Lo bueno de esta opción es que no solo actualiza el sistema operativo sino que permite actualizar cualquier producto que tengamos instalado y detecte parches para el mismo. También podríamos utilizar este sistema en empresas pero requiere que entremos equipo por equipo a chequearlo.

Actualiza parches de seguridad, service packs, drivers, feature packs, etc. Justamente uno de los puntos negativos es el hecho de requerir intervención manual sobre el equipo. Podemos programarlo para que sea automático pero perderíamos total control del ambiente. No se puede planear una distribución, no se puede hacer inventario, etc. Es bastante básica y justamente sirve para las necesidades del usuario final.

Otra opción que venimos mencionando seguido y un producto que deja que hablar es Windows Server Update Services. Una herramienta muy completa para empresas, pequeñas, medianas y en algunos casos para grandes compañías también. Posee todos los beneficios de Microsoft Update, pero además se le suma el hecho de poder planear una implementación, poder ver un status de los equipos parchados como hacer ciertos reportes, existe flexibilidad a la hora de realizar los parchados, etc. Igualmente si bien es bastante útil y poderoso sigue siendo simple. Como opción gratuita es muy buena y completa. Podemos tener total control de nuestro ambiente a nivel de seguridad del sistema operativo y podemos encadenar nuestras oficinas para que también esten al día aunque no tengan conexión a internet.

Otra opción muy conocida ya de hace tiempo es el SMS 2003 o su reemplazo el System Center Configuration Manager 2007. Esta sería la opción mas avanzada, la mas trabajada y la mas robusta. Si tenes un gran enterprise, esta es tu opción recomendada. Posee todos los puntos nombrados anteriormente y mucho mas. No solo que cada punto anterior es mucho mas avanzado sino que además agrega features. Desde ya el producto no sólo se utiliza para parchado, eso es lo mínimo para su función, pero en este artículo únicamente hablamos del parchado. Puede actualizar cualquier sistema Windows. Se puede instalar cualquier tipo de update, incluso se puede agregar updates que se instalen en equipos Windows. Control a la hora de distribuir parches, programar los mismos de manera avanzada, reportes avanzados sobre el ambiente, planeamiento avanzado, administración de inventario avanzado, etc. Un verdadero monstruo para los parches de sistema. Enfocado mas que nada para grandes empresas.

Por ultimo queda mencionar el System Center Essentials 2007. Este producto nos permite administrar nuestro ambiente IT. Diseñado para embientes medianos donde la cantidad de equipos no supere los 500. Lo interesante de este producto es que se pueden agregar parches de terceros para distribuir en nuestro ambiente. Otros archivos .msi o .exe se pueden agregar lo que permite actualizar otros productos también. El resto de los features es muy similar al producto anterior salvo que la mayoría en vez de ser avanzado es de categoría intermedio. Pero como dije antes, no sólo se utiliza para el parchado por lo que nos brinda unos beneficios extra.

Ojo, Microsoft no ofrece las unicas herramientas para administración del parchado, también tenemos Update Expert de Shavlik o sino podemos optar por la reciente compañía adquirida por HP, Opsware que es un producto diseñado para la administración de todo el datacenter incluyendo el parchado de equipos.

Una herramienta que no mencioné pero hay que comentarla es la MBSA: Microsoft Baseline Security Analyzer. Con esta herramienta podemos conocer si nuestros equipos estan parchados o no. Ya con la herramienta WSUS podemos hacerlo obteniendo un hermoso reporte, pero también podemos ejecutar esta herramienta que no solo chequea por parches sino que también revisa configuraciones de seguridad, por ejemplo del IIS o del SQL. Es un excelente aliado a la hora de revisar la seguridad de nuestro ambiente.

Bajo esta experiencia se dio cuenta que sí requiere tomar backup del WSUS. No tanto de los parches bajados pero si de las configuraciones y de los parches aprobados y cuales no, que es uno de los puntos mas importantes. No vaya a ser que luego se apruebe algo que no estaba probado. Por eso creo conveniente hacer un mini tutorial de cómo hacer backup a una instalación de WSUS por defecto. Luego haré uno sobre si la base de datos está en un servidor externo.

El backup que voy a plantear es utilizando la herramienta ntbackup incluída en Windows 2003. Recordemos que en 2008 no viene esta herramienta por defecto, sino que viene Windows Backup y no soporta la misma utilización. Si utilizamos una base de datos externa debemos realizar el backup desde el administrador de SQL 2005.

La información importante para resguardar de WSUS es:

• Base de Datos
  Contiene la metadata de los updates, la configuración del servidor y la información de los clientes
• Contenido
  El directorio con el contenido bajado de internet \WSUS\WSUSContent
• Directorio de Reparación de WSUS
  Donde se guardan los .msi para repararlo \WSUS\UpdateServicesPackage

Realizar el Backup

1. Ejecutamos el comando ntbackup.exe para abrir la aplicación con la que realizaremos el backup.

2. Si abrimos la aplicación en modo de asistente debemos seleccionar la opción "Back up files and settings" y el siguiente paso debe ser "Let me choose what to back up".

3. Cuando nos pregunte qué queremos hacer backup "Items to Back Up" debemos seleccionar el directorio WSUS raíz. En mi caso C:\WSUS.

4. En el paso siguiente nos va a preguntar dónde queremos guardar el backup y con qué nombre. Si tenes una unidad de cinta instalada podes enviarlo a esa unidad, sino podes seleccionar "Let me choose a location not listed here..." y ahí lo podemos guardar en el disco del servidor. Luego ese archivo puede ser tomado por otro servidor de Backup centralizado, asegurándonos de tener un backup con una herramienta que nos sirva para hacer el restore. En el campo del nombre podemos poner lo que querramos.

Si seleccionamos "Let me choose...." debemos hacer click en el botón de Browse y elegir la ruta del disco donde queremos dejar el backup con extensión *.bkf.

5.  Por último veremos cómo se realiza el backup, con el tiempo estimado del mismo, tamaño, etc. En la pantalla anterior se podía definir algunos parámetros extra como si queremos que sea incremental, full, etc. Recomiendo siempre hacer un backup Full en caso que no sea mucho el tamaño, que así es por lo general.
Al finalizar podemos ver un reporte del trabajo realizado, que en si es revisar el log del backup en formato texto.

Recuperando el Servidor

Bueno, lo facil ya se hizo, tomamos un backup, pero cómo hacemos para recuperar el servidor o realizar un restore de la información y configuración sobre el mismo equipo y dejar el servicio operativo?

1. Nuevamente ejecutamos el comando ntbackup.exe para abrir la aplicación con la que realizaremos el restore.

2. Ahora en vez de seleccionar "Back up" debemos seleccionar "Restore files and settings" y luego cuando nos pregunte qué queremos hacer restore marcamos el directorio WSUS completo desde el último backup realizado que nos aparecerá en la pantalla.

3. Cuando pasemos esas pantallas tendremos el resumen final y en el botón "Advanced" podemos cambiar la ruta donde queremos hacer el restore, lo ideal para recuperar el servicio es "Original Location", luego si queremos pisar los archivos que actualmente existen o no, y por último la seguridad de dichos archivos.
Hacemos click en Finish y va a realizar el restore del servicio a su estado anterior.

Faltan todavía un par de puntos a revisar y chequear. Por ejemplo, uno es que cada servidor de WSUS tiene un ID único, si hacemos restore a mas de un servidor del mismo árbol de WSUS no nos va a traer la info del mismo, lo cual mucho no nos sirve. El otro punto por ejemplo es que debemos reciclar el Application Pool de WSUS para que tome el restore que hicimos y un último paso sería resetear el WSUS para que tome la actualización de contenido que hicimos.

Reciclando el Application Pool:

1. Abrimos la consola de Administración del IIS.
2. Bajo el servidor de WSUS vamos a encontrar Application Pools y Web Sites. Dentro de Application Pools vemos WsusPool.
3. Hacemos click derecho sobre WsusPool y elegimos "Recycle".

Resetear el WSUS:

1. Abrimos un Command Prompt con el comando cmd.exe desde Start - Run.
2. Navegamos hasta el directorio de instalación de Update Services, en mi caso "C:\Program Files\Update Services\Tools".
3. Ahí ejecutamos el comando wsusutil.exe reset. 

Si bien ya había escrito algunos artículos sobre WSUS, el unico Tutorial que había armado es implementarlo sobre plataforma Windows Server 2008 ya que es la novedad del SP1 de WSUS 3.0. Creo que serviría hacer un tutorial sobre la instalación de este producto, paso a paso en plataforma Windows Server 2003 como para complementar. Comentando los requisitos mínimos, instalación y configuración básica.
 

Para repasar los requisitos mínimos de implementación de WSUS en Windows Server 2003 los voy a listar a continuación:

• Microsoft Internet Information Services (IIS) 6.0
• Instalar el hotfix KB842773 (Update for Background Intelligent Transfer Service (BITS) 2.0 and WinHTTP 5.1 Windows Server 2003)
• Microsoft .NET Framework 2.0 [Bajar »]
• Microsoft Report Viewer 2005 [Bajar »]
• Microsoft Management Console (MMC) 3.0 para Win Server 2003 (KB907265)

En el caso de Windows Server 2008 ya los había comentado en el post anterior pero viene bien repasarlos:

• Microsoft Internet Information Services (IIS) 7.0
  • Windows Authentication
  • ASP.NET
  • 6.0 Management Compatibility
  • IIS Metabase Compatibility
• Microsoft Report Viewer 2005 [Bajar »]
• Microsoft SQL Server 2005 Service Pack 1 [Bajar »]

Para mas detalles sobre la implementación de este servidor bajo Windows Server 2008 te invito a que revises los documentos ya realizados sobre WSUS en dicha categoría. Artículos sobre WSUS »

Ahora bien, si cumplimos con todos estos requisitos podemos pasar a la instalación del servicio. Obviamente habría que hacer un análisis previo de dónde conviene instalar el servidor en nuestro ambiente, cuántos Servidores WSUS van a existir, anchos de banda, etc. Imaginemos que este análisis ya está realizado y vamos a instalar el primer servidor de WSUS.

Instalación

1. Hacemos doble click sobre el archivo de instalación, por lo general WSUSSetup.exe y hacemos click en Next cuando aparece la bienvenida. Seleccionamos "Full Installation" y luego aceptamos la licencia para poder comenzar. En mi caso el instalador es WSUS3.0SP11Setup.exe.

5. Luego de pasar esa selección debemos seguir con el Asistente hasta finalizar y que comience con la instalación del mismo para luego continuar con la configuración.

Configuración

Al finalizar la instalación va a aparecer un asistente para la configuración inicial. Sugiero que se haga en ese momento por mas que se pueda cancelar y abrir luego desde la consola, es preferible terminar de configurarlo en ese instante así ya queda casi en producción.
Debemos garantizar que el equipo pueda conectarse a Internet (Microsoft Update Site) o bien al servidor WSUS de Updates superior para poder conseguir los parches. En caso de no poder comunicarse a Internet verificar mas abajo qué es necesario para la conexión a internet.

1. WSUS requiere acceso a ciertos sitios de Internet que deberían estar habilitados en el Firewall o en el Proxy server de tu compañía. Los sitios son los siguientes:

http://windowsupdate.microsoft.com
http://*.windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://*.update.microsoft.com
https://*.update.microsoft.com
http://*.windowsupdate.com
http://download.windowsupdate.com
http://download.microsoft.com
http://*.download.windowsupdate.com
http://wustat.windows.com
http://ntservicepack.microsoft.com

Se debe garantizar el acceso a dichos links para que WSUS funcione correctamente. Este es un punto que se puede resolver previo a la instalación del servicio así no te encontras con problemas a la hora de bajar los parches.

2. El primer paso de configuración es definir si el servidor va a bajar los parches desde Microsoft Update o los va a sincronizar de otro servidor de WSUS. Este punto va a depender de la implementación que tengamos. En este caso va a bajarlos desde Internet, pero podría ser un servidor de un site remoto que sincronice contra el del site central. Para ese caso podríamos configurar el modo SSL e incluso podríamos definir en este paso si el servidor es una réplica del central.

3. Al siguiente paso debemos definir si va a utilizar un servidor Proxy para el acceso a internet o bien se conecta directamente. Esta configuración depende de cada organización. Una vez configurado el acceso a internet el servidor ya intentará conectarse para poder bajar la lista de productos actualizada, lenguajes disponibles y tipos de parches.

4. Si la conexión fue exitosa podremos configurar el lenguaje que deseamos contenga nuestra plataforma, los productos de los cuales queremos que chequee los parches y además baje parches disponibles y por último la clasificación de los parches que deseamos, ya sean Updates, Security Updates, Critial Updates, Service Packs, etc. Luego de seleccionar estos tres parámetros debemos configurar el calendario de sincronización de cuándo queremos que se conecte a internet a bajar dichos parches.

5. Como último paso nos va a preguntar si queremos abrir la consola administrativa al finalizar la configuración y si queremos que inicie la sincronización inicial. Estos pasos son optativos, es mas podemos obviar la sincronización si queremos y dejarla programada para la noche para no saturar el acceso a Internet.

El servidor ya está listo para operar y entregar parches a las PCs y Servidores que configuremos. Igualmente quedan un par de puntos para configurar.

1. Dentro de la Consola de Administración » Options » Automatic Approvals. En esta ventana podemos definir reglas de parches que deseemos que automáticamente sean aprovados para instalar, por ejemplo, Definiciones de Windows Defender. Es algo que seguro aprovaremos para todos los equipos así que conviene dejarlo en automático, pero igualmente depende de cada organización. En la segunda solapa de esa ventana "Advanced" vamos a configurar cómo WSUS va a tratar los parches para él mismo y para la plataforma de WSUS.

2. Otro issue importante son las notificaciones por correo que también las configuramos desde Options » E-Mail Notifications. Podemos configurar diferentes alertas para que lleguen a nuestra casilla de correo y obviamente requiere configurar el servidor de correo.

Qué falta para terminar de configurarlo y que entregue parches ?
Unicamente crear los grupos de PCs (optativo) y configurar las PCs y Servidores con los parámetros del WSUS Server. Este punto lo voy a comentar en detalle luego, tanto para hacerlo manualmente, a través de Registry o bien a través de GPO (política) de dominio.

Link | Download Windows Server Update Services 3.0 SP1
Link | Microsoft Windows Server Update Services 3.0