На блоге Ильи Сазонова обнаружил очень интересный материал: WSUS – сверка списка компьютеров с AD. Да и вообще, там регулярно появляется любопытная информация.

Позволю себе перенести то, что он выложил к себе с некоторыми моими комментариями и модификациями.

Что это и зачем это нужно? В каждой уважающей себя организации используется Active Directory как единый каталог и WSUS для централизованной установки обновлений. Но, по разным причинам, некоторые компьютеры могут не обновляться со WSUS. Причины тому могут быть самые разные: сбой агента обновления, файрволл, еще что-то … Главное – это то, что такие случае нужно выявлять и разбираться с ними индивидуально.

Итак

Текущая версия WSUS имеет API, который позволяет удаленное управление сервером. Чтобы его задействовать, необходимо установить на компьютер клиентскую часть сервера. После чего запускаем оболочку Powershell 2.0 и загружаем WSUS API:

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")

   Теперь надо подключаемся к удаленному серверу по имени «WSUS»:

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("WSUS", $false)

   Второй параметр $false говорит о том, что будет использоваться HTTP протокол, а не HTTPS, т.е. не будет шифрования.

Скрипт Ильи работает, если у вас WSUS висит на стандартном порту. У меня же он висит на другом, нестандартном. Как поступить? А вот как (спасибо коллеге, нашел):

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("WSUS", $false,port_number)

Где port_number – номер нестандартного порта WSUS

   Теперь получаем список всех компьютеров зарегистрированных на WSUS-сервере:

$WSUScomps = $wsus.GetComputerTargets()

   Каждый элемент массива $WSUScomps это объект, а нам нужны только имена компьютеров. Получаем FQDN имена компьютеров:

$WSUSCompNames = $WSUScomps | ForEach { $_.FullDomainName.ToUpper() }

   Перевод имени в верхний регистр не критичен (по умолчанию Powershell выполняет сравнение строк без учета регистра), но формально все же это надо сделать.

   Следующий шаг – получение списка учетных записей компьютеров из Active Directory:

$ADcomps = (new-object System.DirectoryServices.DirectorySearcher([ADSI]LDAP://ou=DEPS,dc=DOMAIN,dc=com,"(&(objectCategory=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2))")).findAll()

   Тут конструкция !userAccountControl:1.2.840.113556.1.4.803:=2 исключает запрещенные (disabled) учетные записи компьютеров. LDAP://ou=DEPS,dc=DOMAIN,dc=RU задает корень поиска в дереве AD. objectCategory=computer – выбираем только учетные записи компьютеров.

   Из объектов учетных записей компьютеров извлекаем имена компьютеров (также формально переводим их в верхний регистр):

$ADCompNames = $ADcomps | ForEach {$_.GetDirectoryEntry().dNSHostName.ToString().ToUpper()}

   И последний шаг – получаем имена компьютеров, которые есть в Active Directory, но отсутствуют в WSUS:

$NoWSUSCompNames = $ADCompNames | Where { $WSUSCompNames -notcontains $_ }

   Теперь нам остается проанализировать полученный список и разобраться почему выявленные компьютеры не получают обновления с WSUS.

Позже выложу те скрипты, с помощью которых мы “чиним” агентов WSUS на клиентских компьютерах и серверах.

Buenas.

Primero de todo comentaros que los filtros WMI son muy útiles en muchos casos. Para que tengáis una forma sencilla de realizar un filtro WMI y sin complicaros mucho os dejo este link de una herramienta que directamente os creará la select WMI que deberéis usar en otros programas por ejemplo desde las GPO de Active Directory.

El programa es WMI Code Creator: http://www.microsoft.com/downloads/details.aspx?FamilyID=2cc30a64-ea15-4661-8da4-55bbc145c30e&displaylang=en

Os enseño un poquillo como funciona. Arrancáis el programa:

Seleccionáis en el campo Classes la clase que queráis por ejemplo en este caso necesitaremos saber si el espacio disponible en disco es mayora a 2GB pues bien pulsamos sobre Win32_LogicalDisk

Ahora en Select the properties you want values for seleccionamos FreeSpace.

Pulsamos sobre Search for Property Values para comprobar algunas posibilidades de este filtro WMI.

Pulsamos sobre FreeSpace.

En la pantalla de la derecha Generated Code: Comprobamos que la consulta WMI que deberemos usar es: SELECT *FROM Win32_LogicalDisk WHERE FreeSpace = 200867135488”,,48)

Ahora ya tenemos una consulta WMI que podemos usar a nuestro antojo modificándola un poquito.

Como estábamos hablando de WSUS en artículos anteriores vamos a realizar en este caso un filtro WMI en Active Directory a través de la herramienta Group Policy Managment Console.

Arrancamos el Domain Controller por ejemplo si no disponemos de una consola de GPMC en nuestro equipo cliente y arrancamos la GPMC.

Pulsamos con el botón derecho del ratón sobre Filtros WMI como en la imágen anterior y pulsamos sobre Nuevo

Escribimos el nombre del filtro WMI y la Descripción y pulsamos sobre Agregar.

Escribimos la consulta que hemos conseguido antes gracias al programa WMI Code Creator y la modificamos para que el valor de FreeSpace se cumpla cuando sea mayor a 2147483648 (Bytes) que son los 2GB que hablábamos. Por si no queréis calcularlo a mano os dejo este link de transformación de bytes a kb,GB, etc.. http://www.wilkinsonpc.com.co/free/articulos/calculadorabytes.html.

SELECT *FROM Win32_LogicalDisk WHERE FreeSpace > 2147483648

Y pulsamos sobre Aceptar.

Pulsamos sobre Guardar.

Ahora que ya tenemos el filtro WMI creado se lo vamos a asignar a una política de grupo (GPO).

Nos situamos encima de la GPO a la que se lo queramos aplicar y abrimos el desplegable Este GPO está vinculado con el siguiente filtro WMI: y seleccionamos el filtro WMI Espacio mayor a 2 GB.

Pulsamos sobre Sí.

A partir de ahora esta GPO únicamente se aplicará en equipos que dispongan de un espacio en disco mayor a 2GB.

Espero que os haya sido útil.

Hasta pronto MegaCracks.

Hi,

zur Zeit gibt es Probleme mit dem WSUS Server und dem Update KB931125 Stammzertifikate.

Den Clients wird das Update immer und immer wieder angeboten.

Lösung: alle Stammzertifikate (inkl. Mai – September) verweigern und nur das Stammzertifikate (inkl. November) freigegeben.
Auf den Clients muss dann ggf. noch folgendes ausgeführt werden:

1. Stopp des Automatischen Update oder Windows Update Dienstes
2. den Inhalt des Verzeichnisses “C:\WINDOWS\SoftwareDistribution” löschen (“rd /s /q %windir%\SoftwareDistribution”)
3. Neustart des Automatischen Update oder Windows Update Dienstes oder Neustart der Clients

Quelle: Root Certificate update KB931125 keeps installing

Na dann, Viel Spass beim selber Testen!
CU

Partiendo de la instalación del artículo anterior vamos a mostrar como configurar el servidor WSUS para que se ponga a distribuir parches de inmediato.

Entramos en el servidor WSUS. En la consola Server Manager de Windows Server 2008 que podéis abrir desde Inicio –> Herramientas administrativas –> Server Manager .

Nos situamos en Roles –> Windows Server Update Services –> Update Services –> Options y pulsamos sobre WSUS Server Configuration Wizard.

Comprobamos los 3 puntos antes de seguir y pulsamos sobre Next.

En caso de querer ayudar a Microsoft a mejorar WSUS marcad la opción Yes, i would like to join the Microsoft Update Improvement Program. Esta opción enviará información a Microsoft sobre cuantos equipos tenemos en la organización, cuantos updates han sido satisfactorios y cuantos han fallado.

Pulsamos sobre Next.

En esta pantalla nos da la opción de que este servidor sea el que sincronizará con Microsoft Update o en el caso que estemos instalando un servidor secundario de WSUS marcar la segunda opción para introducir el nombre del servidor desde el que se sincronizará WSUS. (En nuestro caso como va a ser una instalación simple sin servidores en Branch Offices y como además es el primer servidor WSUS (principal) lo dejaremos con esta opción marcada por defecto) y pulsamos sobre Next.

En el caso que este servidor requiera de un proxy para poder acceder a internet para descargar actualizaciones introduciremos sus datos en otro caso pulsamos sobre Next.

Pulsamos sobre Start Connecting. Esto hará que WSUS descargue y nos muestre las diferentes opciones que podremos configurar de idiomas, tipos de parches, y tipos de producto.

Pulsamos sobre Next.

En esta pantalla se nos da la opción de o bien sincronizar WSUS con todos los parches de todos los idiomas o bien únicamente de los idiomas que seleccionemos. (Os recomiendo que sin no estáis seguros del idioma de los sistemas operativos que tenéis dejéis marcada la opción por defecto de todos los idiomas).

Esto no descarga todos los parches de todos los idiomas.

Únicamente sincroniza con Windows Update para mostrar todos los parches disponibles de todos los idiomas que nosotros más tarde aprobaremos para su distribución. En caso de que los idiomas de los equipos a los que vayamos a distribuir parches sean únicamente por ejemplo español e inglés podremos descargar tras aprovar su instalación únicamente los parches para estos 2 idiomas.

Recordad. NO descarga los parches en ningún momento. Únicamente los muestra para su aprobación. (Os lo explicaré mas adelante en este mismo artículo).

En nuestro caso como tenemos claro que sistemas operativos y que idiomas disponemos únicamente marcamos Español e inglés para que la sincronización sea más rápida.

Pulsamos sobre Next.

Esta pantalla nos ofrece la posibilidad de marcar únicamente los productos que vamos a sincronizar para poder aplicar parches. En nuestro caso como únicamente le vamos a actualizar los parches a los servidores vamos a marcar las opciones Exchange, OCS, Windows Servers, etc… En vuestro caso marcad las opciones que mejor se adapten a la funcionalidad de este WSUS y al terminar pulsad sobre Next.

Recordad que tanto los idiomas como los productos se podrán configurar en otras ocasiones en caso que sean necesarias sin tener que pasar por todo el wizard.

Aquí se nos da la oportunidad de descargar varios tipos de actualizaciones. Por defecto están marcadas las de la imagen anterior. Pero nosotros lo vamos a modificar para que descargue Service Packs y Update Rollups. Ya que en caso necesario podríamos distribuir los Service Pack a través de la consola WSUS sin tener que conectar-nos servidor a servidor y descaragar e instalar el Service pack. Los Update rollups también los marcamos ya que son acumulaciones de parches que son útiles en ocasiones para no tener que descargar todos los parches uno por uno, en update rollups vienen paquetizados.

Marcamos las opciones que más os convengan y pulsamos sobre Next.

Marcamos la opción Synchronize automatically y ponemos una hora prudencial en para no afectar al ancho de banda de internet de los usuarios de nuestra corporación y pulsamos sobre Next.

Marcamos la opción Begin initial synchronization pensando en lo que acabo de decir. Si no afectamos al ancho de banda de los clientes. Esto realizará una primera sincronización de las configuraciones anteriores.

Pulsamos sobre Next.

Aquí se nos muestran varios enlaces para ayudar a configurar WSUS. Nosotros pulsamos sobre Finish.

Comprobamos que la sincronización se está efectuando en el apartado Synchronizations.

Mientras está sincronizando vamos a configurar la estructura de las actualizaciones.

Por ejemplo en el caso que queramos separar las actualizaciones por empresas para tener un report claro de como estamos a nivel de parches en cada empresa crearemos un grupo por empresa.

En caso que queramos hacerlo por departamentos pues crearemos tantos departamentos como queramos.

En nuestro caso como ya hemos dicho antes únicamente vamos a actualizar los servidores así que primeramente crearemos un grupo llamado BeforeDeploy para poder albergar una serie de servidores donde descargaremos e instalaremos los parches y chequearemos su estado, para más tarde por ejemplo una o 2 semanas distribuir estos mismos parches a todos los demás servidores de la empresa. (Esta es una buena práctica ya que en caso q uno de los parches instalados provoque un mal funcionamiento del servidor únicamente nos afectará a un grupo reducido. El grupo BeforeDeploy os recomiendo que en este grupo tengáis un servidor de cada tipo, por ejemplo un Domain Controller, un Exchange, un Sql, etc… para poder testear los parches con las diferentes funcionalidades de cada servidor.

Para ello tras situarnos sobre Computers pulsamos con el botón derecho del ratón sobre All computers y pulsamos sobre Add Computer Group.

Escribimos el nombre del grupo y pulsamos sobre Add.

Nosotros creamos otro grupo llamado AllServers para albergar todos los demás servidores.

NOTA: Para poder ubicar los servidores en cada grupo disponemos de 2 opciones. O bien hacerlo mediante directivas de grupo o bien moviendo manualmente cada servidor dentro de WSUS a su grupo.

Nosotros para hacerlo más difícil y también más manejable lo haremos mediante directivas de grupo. Primero debemos configurar WSUS para que acepte este tipo de instrucción pero deberemos esperar a que termine de sincronizar para poder modificar estas opciones.

Mientras tanto iremos creando la estructura de Active Directory para poder vincular las directivas de grupo de una forma más sencilla.

Nos situamos en el controlador de dominio más cercano y entramos en la consola de Usuarios y Equipos de Active Directory. Inicio –> Herramientas administrativas –> Usuarios y equipos de Active Directory.

Creamos las unidades organizativas como queráis. Nosotros vamos a crear una unidad organizativa que llamaremos BeforeDeploy y otra que llamaremos AllServers. (No hace falta que se llamen igual que los grupos de WSUS pero ya que estamos los vamos a distribuir de la misma forma).

Para hacerlo ya sabéis: Botón derecho sobre la unidad organizativa o parte del árbol del directorio activo donde queráis ubicar estos servidores y nuevo –> Unidad organizativa.

Ahora deberemos mover los servidores a estas unidades organizativas.

ATENCIÓN: Los Domain Controllers no os recomiendo que los mováis de OU (Unidad organizativa) ya que en caso de moverlos dejarán de aplicarse-les directivas de grupo específicas de controladores de dominio.

Ya aplicaremos una directiva de grupo sobre la unidad organizativa de Domain controllers para que también se les actualicen los parches del sistema. (No os preocupéis por ello).

En caso de que por error los hayáis movido volvedlos a mover a su unidad organizativa, no pasa nada se les volverán a aplicar las directivas y listo.

Bueno ahora que ya tenemos la estructura de OU’s creada y los servidores movidos a ellas, únicamente nos faltará crear las directivas de grupo para que sepan que servidor de actualizaciones usar para descargar los parches, en que momento, etc..

Ahora en el domain controller ejecutamos la herramienta Group Policy Management console. Inicio –> ejecutar –> gpmc.msc. En windows server 2008 ya está incluida pero en windows server 2003 y anteriores no.

En caso de no disponer de la herramienta nos la descargaremos del siguiente enlace: http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887&displaylang=en

Instalamos la aplicación pulsando doble click sobre el fichero descargado.

Tras instalar la aplicación pulsamos sobre Inicio –> ejecutar –> gpmc.msc

Nos situamos sobre Bosque: vuestro bosque –> Dominios –> vuestro dominio.

Pulsamos con el botón derecho del ratón sobre Objetos de directivas de grupo –> Nuevo

Escribimos un nombre y pulsamos sobre Aceptar.

Ahora pulsamos con el botón derecho sobre la directiva y editar.

Nos desplazamos por Configuración del equipo –> Plantillas administrativas –> Windows Update.

Únicamente os voy a comentar la configuración simple para que los equipos aparezcan en vuestro WSUS, vosotros podéis leer todas las opciones posibles de la directiva respecto a cuando instalar los parches, cuando sincronizar, etc…

Primero pulsamos doble click sobre Especificar la ubicación del servicio Microsoft Update en la intranet.

Marcamos Habilitada y en los dos campos posibles escribimos la dirección que nos dio el servidor WSUS cuando lo instalamos (http://<nombre del servidor>) y pulsamos sobre Aceptar.

Ahora pulsamos doble click sobre Habilitar que el cliente pueda ser un destino.

Marcamos Habilitada y ponemos el nombre del grupo que hemos creado en WSUS que es donde se ubicarán los equipos y pulsamos sobre Aceptar.

Ahora pulsamos doble click sobre Configurar actualizaciones automáticas.

Marcamos Habilitada y la configuramos como queramos, de momento pondremos la opción 3 que descargará las actualizaciones desde WSUS y notificará para la instalación.

Como únicamente necesitamos estos 3 valores para que el servidor WSUS vea a los equipos como clientes cerramos la edición de la GPO. Vosotros seguid configurando las opciones posibles para adaptarlo correctamente.

Lo que vamos a hacer ahora es hacer una copia de la directiva ya que únicamente le vamos a cambiar el valor del nombre de grupo de destino para este equipo por AllServers.

Ahora vamos a vincular estas GPO a sus Unidades organizativas correspondientes.

Nos situamos en la Unidad organizativa donde vamos a vincular la GPO y pulsamos con el botón derecho sobre ella y sobre Vincular una GPO existente.

Seleccionamos la GPO y pulsamos sobre Aceptar.

Hacemos el mismo procedimiento para las demás unidades organizativas y también para la de Domain Controllers. Quedando el árbol de la siguiente forma:

En nuestro caso hemos creado 2 directivas una para Before Deploy y la otra para Todos los servidores restantes.

Recordad que deberéis crear una directiva por cada grupo que hayáis creado en WSUS ya que en esta directiva se configurará el grupo al que se le aplicarán los parches.

NOTA: En caso de no necesitar saber los parches instalados por departamento o por empresa os recomiendo crear los 2 grupos mencionados el BeforeDeploy y el restante. Pero vosotros sois los que sabéis como queréis implementar los parches.

Podéis hacerlo por servidores y workstations por ejemplo. Bueno.. vosotros sabréis.

Ahora vamos a forzar la aplicación de estas directivas a los servidores.

Nos situamos en cualquier servidor y o bien lo reiniciamos o bien Inicio – > Ejecutar –> gpupdate /force esto provoca una solicitud de actualización de su GPO al domain controller.

Ahora que el sistema ya es capaz de encontrar su servidor de actualizaciones y de saber en que grupo de WSUS ubicarse vamos a forzar el envío de datos desde el cliente hacia el servidor WSUS. para ello Inicio –> Ejecutar –> wuauclt /detectnow.

Volvemos a comprobar si el servidor WSUS ha terminado de sincronizar el catálogo.

Si es el caso nos situamos sobre Options –> Computers del menú de Windows Server Update Services(WSUS).

Marcamos la opción Use Group Policy or registry settings on computers y pulsamos sobre OK.

Eso habilita la funcionalidad de catalogar los equipos mediante las directivas de grupo que hemos configurado en Active Directory.

Después de aplicar este cambio y de que los equipos hayan actualizado sus directivas de grupo vamos a comprobar si existen servidores catalogados en WSUS.

Pues en efecto, en los 2 servidores que le hemos realizado el gpupdate /force aparecen y en el grupo correcto.

En el caso que no veáis información sobre ellos o bien nos esperamos las 22 horas por defecto o forzamos a que envíen y actualicen sus datos. Desde los clientes ejecutamos los comandos wuauclt /detectnow y wuauclt /updatenow.

Bueno pues ya tenemos información de uno de ellos. Vemos que tiene un 96% de parches instalados. Podemos ver mas columnas pulsando con el botón derecho sobre las actuales columnas y marcando las opciones que deseemos. Needed count nos mostrará los parches que le faltan por instalar a los equipos.

Pues puedo comprobar que el servidor firstdomain.megacrack.es le faltan 62 parches.

Ahora vamos a aprovar los parches para su descarga y posterior instalación en el equipo cliente.

Desde WSUS pulsamos sobre Updates –> All updates.

Como vemos en el campo Approval dejamos marcado Unapproved y en el campo Status dejamos marcado Failed or Needed con esto conseguimos ver únicamente los parches que necesitan todos los equipos ubicados en WSUS.

Para descargar los parches para que puedan ser aplicados a los equipos hemos de aprovarlos.

Seleccionamos todos los parches y con el botón derecho del ratón pulsamos sobre Approve.

Ahora pulsamos sobre BeforeDeploy pulsamos sobre Approve for Install.

La idea sería que al cabo de 2 semanas  por ejemplo tras haber probado estos parches se podrían aprobar también para la categoría AllServers.

Pulsamos sobre OK.

Los parches se aprobarán y pulsamos sobre Close.

Ahora los parche se irán descargando y según la política de grupo que hemos creado anteriormente en los equipos del grupo BeforeInstall les aparecerá un icono indicando que tiene parches para instalar.

Pues bien para aprobarlos para los demás grupos deberemos seleccionar en Updates –> All updates en el campo Approval dejamos marcado Approved y en el campo Status dejamos marcado Failed or Needed con esto conseguimos ver únicamente los parches que necesitan todos los equipos ubicados en WSUS y podremos aprobarlos para AllServers.

Pues creo que esto es todo.

Si tenéis cualquier duda, ya sabéis un comentario y os responderé cuando tenga algo de tiempo.

Espero que os sea de utilidad.

Saludos y hasta pronto MegaCracks.

Buenos días.

Hoy os voy a mostrar como instalar un servidor WSUS sobre Windows Server 2008 R2 x64. Wsus es un sistema de distribución y reporting de parches de Microsoft.

Voy a realizar una implementación simple, WSUS se puede montar sobre Windows XP, Windows Server 2003 pero en Windows Server 2008 ya viene como un ROL y únicamente deberemos descargar un programa para hacer los reports (Que luego os explico). Se puede instalar sobre una base de datos local incluida en el WSUS o incluso se puede instalar un servidor SQL y montar la base de datos en local o remotamente.

Wsus lo montaré sobre un equipo con 1 GB de RAM, 1 CPU y 2 discos (C:\20 GB que albergará Sistema Operativo, base de datos y archivo de paginación y D:\ 20 GB donde se ubicarán los parches descargados por defecto). Con estas especificaciones podremos disponer de un sistema de actualización de parches para unos 300 servidores. En el caso que el parque de servidores o de Workstation que queráis actualizar desde WSUS sea superior deberéis crear el disco d:\ con un mayor tamaño, os recomiendo que instaléis SQL Server para albergar la base de datos en él y por supuesto pongáis la base de datos en D:\ también. NO hay que pasarse.

Bueno a lo que vamos.

Partiremos de un sistema operativo BASE con Windows Server 2008 R2 X64. En el artículo anterior podéis saber como es este base. (En el caso que no tengáis un BASE no os preocupéis los pasos son los mismos exactamente para instalar WSUS, pero partiréis de la pantalla de ROLES en lugar de desde el principio del artículo, (No es complicado así que no os asustéis).

Como el sistema operativo ya está preinstalado en el BASE que realicé os voy a mostrar pantalla a pantalla todo el proceso después del BASE.

Arrancamos la máquina desde el BASE.

Pulsamos sobre Next.

Marcamos I accept the licences terms y sobre Start.

Pulsamos sobre OK. Para cambiar la contraseña del administrador local.

Ponemos la contraseña y pulsamos sobre el icono Azul.

Pulsamos sobre OK.

Ahora ya tenemos el sistema arrancado.

Ahora cambiamos el nombre del servidor, pensad que el nombre que tenga será el enlace a los clientes para que se puedan descargar los parches. Es decir os avanzo que crearemos una directiva de grupo en el domain controller y se la asignaremos a una unidad organizativa configurando que el servidor de donde descargaremos las actualizaciones será el que vamos a crear ahora. Por ejemplo el nombre del servidor podría ser LocalWindowsUpdate. Únicamente os digo esto para que no haya malos entendidos en la configuración de los clientes.

Aquí es donde empieza realmente el proceso de instalación del Role WSUS.

Primero de todo deberemos disponer de conexión a Internet para que el programa pueda instalarse correctamente.

Para comprobarlo descargaros el siguiente fichero e instalarlo desde el siguiente enlace: http://www.microsoft.com/downloads/details.aspx?FamilyID=cc96c246-61e5-4d9e-bb5f-416d75a1b9ef&displaylang=en , lo necesitaremos tras la instalación.  

Cuando estemos seguros de que el servidor dispone de acceso a internet:

Pulsamos sobre Add roles.

Pulsamos sobre Next.

Marcamos Windows Server Update Services.

Pulsamos sobre Add Required Role Services.

Pulsamos sobre Next.

Pulsamos sobre Next.

Pulsamos sobre Next.

Pulsamos sobre Next.

Pulsamos sobre Install.

Pulsamos sobre Next.

Marcamos I Accept the terms of the License agreement y pulsamos sobre Next.

Aquí debemos poner la ruta donde se descargarán los Updates. Pensad que ocupan bastante y pensad que serán los parches por cada idioma que tengáis en vuestra organización. (Os recomiendo almacenarlo en una unidad distinta a C:\ y así la podréis ampliar a vuestro antojo(Recordad que ahora con Windows Server 2008 es posible redimensionar particiones directamente desde Windows)).

En el caso que no dispongáis de espacio suficiente también tenéis la opción de desmarcar la opción Store updates locally pero cada vez que tengáis que actualizar un equipo se descargará estos parches desde Windows Update y el ancho de banda de la línea se verá afectada.

Pues bien modificamos la unidad por la que os vaya mejor y pulsamos sobre Next.

En este punto nos da la opción de almacenar la base de datos en local, en un SQL local o incluso en un servido SQL remoto. La mejor opción en grandes corporaciones es almacenar la base de datos en un SQL, pero en nuestro caso y si no supera los 300 equipos lo podremos almacenar en local.

Pulsamos sobre Next.

En esta pantalla nos muestra la posibilidad de dejar el servidor web operativo en el puerto 80 o cambiarlo por el 8530, si en este mismo servidor ya disponéis de un servidor web quizá os interese marcar la segunda opción, en cualquier otro caso pulsamos sobre Next.

Repasamos el summary y pulsamos sobre Next.

Pulsamos sobre Finish.

Dependiendo si tenéis o no las actualizaciones automáticas habilitadas os aparecerá este warning. Voy a activarlo desde el panel de control y listo. Pulsamos sobre Close para terminar con la instalación.

Pulsamos sobre Yes para reiniciar.

En otro artículo os explico como configurarlo.

Após uma ajudinha da Microsoft, consegui minimizar meu drama descrito em posts anteriores. Uma pequena luz no fim no túnel apareceu e consegui automatizar a geração de alguns tipos de relatórios.

Primeiramente, instalamos o Microsoft SQL Server Management Studio Express. No meu caso, utilizo o WSUS Internal Database (que fica no mesmo servidor).

Para a conexão ao database, é necessário usar autenticação “Integrated” com a seguinte string de conexão:

\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

A partir daí, já é possível visualizar a estrutura do database (SUSDB), tabelas e views. Entendendo a estrutura básica, já é possível montar uma “query” sql para gerar os dados que queira.

No meu caso, precisava (na verdade preciso mensalmente) de um Report, sobre o status de instalação do último boletim de segurança.

Após alguns dias, consegui montar a seguinte query:

USE SUSDB
DECLARE @strGroup as varchar(20)
DECLARE @strKB as varchar(10)

SELECT @strGroup = 'Nome do Grupo'
SELECT @strKB = '112233' /* número do KB */

select count(*) as Total, uiib.State
from PUBLIC_VIEWS.vUpdateInstallationInfoBasic as uiib
inner join PUBLIC_VIEWS.vComputerGroupMembership as cgm on uiib.ComputerTargetId = cgm.ComputerTargetId
inner join tbComputerTarget as ct on cgm.ComputerTargetId = ct.ComputerID
inner join PUBLIC_VIEWS.vComputerTargetGroup as ctg on cgm.ComputerTargetGroupId = ctg.ComputerTargetGroupId
inner join PUBLIC_VIEWS.vUpdate as u on uiib.UpdateId = u.UpdateId
inner join PUBLIC_VIEWS.vUpdateApproval as ua on uiib.UpdateId = ua.UpdateId
WHERE
ctg.Name = @strGroup
AND u.KnowledgebaseArticle = @strKB
AND ua.Action = 'Install'
GROUP BY uiib.State

A partir daí gerei um vbs pra facilitar minha vida:

GetWSUSData "'All Computers'","'971961'"
GetWSUSData "'All Computers'","'970710'"
GetWSUSData "'All Computers'","'973812'"
GetWSUSData "'All Computers'","'967723'"
GetWSUSData "'All Computers'","'956844'"

Sub GetWSUSData(strGroup, strKB)

	ConnSQL = "Provider=SQLNCLI;Data Source=\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query;Database=SUSDB;Trusted_Connection=yes"
	set rs = CreateObject("ADODB.Recordset")
	rs.ActiveConnection = ConnSQL

	SQL = "select count(*) as Total, uiib.State " & _
	"from PUBLIC_VIEWS.vUpdateInstallationInfoBasic as uiib " & _
	"inner join PUBLIC_VIEWS.vComputerGroupMembership as cgm on uiib.ComputerTargetId = cgm.ComputerTargetId " & _
	"inner join tbComputerTarget as ct on cgm.ComputerTargetId = ct.ComputerID " & _
	"inner join PUBLIC_VIEWS.vComputerTargetGroup as ctg on cgm.ComputerTargetGroupId = ctg.ComputerTargetGroupId " & _
	"inner join PUBLIC_VIEWS.vUpdate as u on uiib.UpdateId = u.UpdateId " & _
	"inner join PUBLIC_VIEWS.vUpdateApproval as ua on uiib.UpdateId = ua.UpdateId " & _
	"WHERE " & _
	"ctg.Name in (" & strGroup & ") " & _
	"AND u.KnowledgebaseArticle = " & strKB & " " & _
	"AND ua.Action = 'Install' " & _
	"GROUP BY uiib.State"

	rs.Source = SQL
	rs.Open()
	Wscript.Echo "Statistics for Groups " & Replace(strGroup,"'","") & " and KBs " & Replace(strKB,"'","")
	While (not rs.eof)
		wscript.echo GetStatus(rs.fields.item("State").value) & "," & rs.fields.item("Total").value
		rs.MoveNext()
	Wend

	rs.Close
	Set ConnSQL = Nothing
	Set SQL = Nothing
	Wscript.Echo ""

End Sub

Function GetStatus(strStatusCode)
	Select Case strStatusCode
	Case 2
		GetStatus = "Not Installed"
	Case 3
		GetStatus = "Downloaded"
	Case 4
		GetStatus = "Installed"
	Case 5
		GetStatus = "Failed"
	Case 6
		GetStatus = "Pending Reboot"
	End Select
End Function

Wsus, sistem yöneticilerinin ağlarında bulunan, Windows işletim sistemine sahip bilgisayarlardaki güncellemeleri (Office, Exchange, SQL, Windows) takip etmelerini sağlayan bir servis yazılımıdır.

• Windows Server 2008 R2 ile uyumludur.
• Windows Server 2008 R2′deki BranchCache özelliğini destekler.
• Windows 7 ve Windows Server 2008 R2 istemcisini destekler.
• Rapor özelliği sunar.
• WSUS 3.0 SP2 yalnız başına yüklenebilir veya WSUS 3.0 SP1′e güncelleme olarak kullanılabilir.

WSUS’u kurmak için minimum sistem gereksinimleri :

1. 6 GB boş disk alanı.

2. System partition NTFS ile formatlanmış olması.

3. IIS 5.0 (Windows 2000) ya da IIS 6 (Windows 2003/R2) kurulu olması gerekir.

4. Net Framework 1.1 SP1.

WSUS 3.0 SP1 için gereksinimler :

Windows Server 2008

Windows Server 2003 SP1 (en az)

IIS 6.0 (en az)

Microsoft .NET Framework 2.0

Microsoft Management Console 3.0

Microsoft Report Viewer

WSUS 3.0 Administration Console için gereksinimler :

Windows XP SP2

Microsoft. NET Framework 2.0

Microsoft Management Console 3.0

Microsoft Report Viewer

• Microsoft Report Viewer sisteminizde kurulu değilse bu durum kurulumu engellemeyecek, fakat yazılımdan rapor alma özelliğini kullanamazsınız. Raporunuzu Excel veya PDF seklinde kaydedebilirsiniz.
• Eğer sisteminizde SQL 2005 sunucunuz varsa database olarak orayı tanımlayabilirsiniz. Eğer yok ise yükleme paketi WSUS Windows Internal Database’i kurarak yapılandıracaktır.

Desteklenen İşletim Sistemleri :

Windows 7; Windows Server 2003; Windows Server 2003 Service Pack 1; Windows Server 2003 Service Pack 2; Windows Server 2008; Windows Vista; Windows Vista Service Pack 1; Windows Vista Service Pack 2; Windows XP Service Pack 3

Windows Server 2008 R2, Windows Server 2008 SP1 or later versions, Windows Server 2003 SP2 or later versions, Windows Small Business Server 2008, Windows Small Business Server 2003 and Windows XP SP3

WSUS Download :

http://www.microsoft.com/downloads/details.aspx?FamilyId=a206ae20-2695-436c-9578-3403a7d46e40&displaylang=en

Yükleme paketi WSUS 3.0 SP2 Server, WSUS 3.0 SP2 Yönetim konsol bileşenleri ve düşük seviye işletim sistemleri için WUA istemcisi yükler.

Adım Adım WSUS Yüklemesi :

1. İnstaller’ı Çalıştırın.
2. Sunucu kurulumu yapıyorsanız ilk seçeneği, eğer kurduğumuz bir WSUS’u istemci bir pc den yönetmek istersek 2. seçeneği seçin.
3. Lisans sözleşmesini kabul edin.
4. WSUS’un update’leri indireceği yeri seçin. Yüksek alan içeren bir bölüm olması faydanızadır.
5. Eğer sisteminizde SQL 2005 sunucunuz varsa database olarak orayı tanımlayabilirsiniz. Eğer yok ise yükleme paketi WSUS Windows Internal Database’i kurarak yapılandıracaktır.
6. IIS üzerinde WSUS’a istemcilerin erişim yapacakları site ayarını yapın. Yerel web sayfasını kullanacaksanız 1. seçeneği, yeni bir WSUS web sitesi oluşturacaksanız 2.seçeneği seçin. 2. seçeneği seçtiğinizde sitenizin sonuna bir port numarası eklenir. Eğer modeminiz dahilinde veya software olarak bir firewall kullanıyorsanız bu porta erişim izni tanımanız gerekir.
7. Ayar Sihirbazından gereken ayarları yapınız.
8. Sistemde birden fazla WSUS varsa ikinci seçeneği seçerek senkronize edebilirsiniz. İlk kurulum için birinci seçeneği seçerek WSUS’u doğrudan Windows Update ile ilişkilendirebilirsiniz.
9. Proxy ayarlarınızı yapın.
10. Start Connection’u seçerek bağlantıyı başlatıp update bilgilerini alalım.
11. Güncelleme yapacağımız yazılımların kullandığı dil paketlerini güncelleme olarak alalım. Office, Exchange, SQL, Windows vs.
12. Güncelleme yapmak istediğimiz alanları seçelim.
13. Güncelleme günlüğü oluşturun.
14. Senkronizasyonu başlat seçeneğini de seçerek kurulumu bitirelim.

(Wsus’a Başlat/Programlar/Yönetimsel Araçlar’dan ulaşılabilir.)

WSUS admin sayfası :

http://wsusserver/WusAdmin

Eğer default olan port numarasından başka bir port atadıysanız :

http://wsusserver:PortNumaraniz/WusAdmin

Adım Adım WSUS Konfigürasyonu

1. Eşitleme bittikten sonra kategoriler halinde gördüğümüz güncelleştirmelerden, Filter kısmından “Unappored” Status kısmından “Any” sorgularını yaptığımızda eşitlemede çektiğiniz liste gelir. Yüklenmesini istediğimiz güncelleştirmeleri seçerek “Approve” seçeneği ile güncelleştirmeye başlıyoruz.
2. Şimdi, istemcilerin bu güncelleştirmelerden haberdar olabilmesi için template ekliyoruz. Wuau template’i editöre ekleyelim.
3. Administrative Templates’e sağ tıklayalım. Add/Remove Templates’i seçin. Wuau.adm dosyasını seçip ekliyoruz.
4. GPO>Computer Configuration>Administrative Templates>Windows Components>Windows Update
5. Configure Automatic Updates > Enabled
6. GPO > Computer Configuration > Administrative Templates > Windows Components > Windows Update
7. Specify intranet Microsoft update service location > Enabled* GPO’nun istemcileri görmesi 15-20 dakika arası zaman alabilir. Bu süreyi beklemek istemiyorsanız “wuauclt.exe /detectnow” komutu ile anında istemcileri belirleyebilirsiniz.
8. Gpupdate /force komutunu çalıştıralım ve istemcileri yeniden başlatalım.
9. İstemci de rsop.msc komutunu çalıştırarak policy ayarlarımızın geçerliliğini sınayalım.

WSUS 3.0′da e-mail bilgilendirmeleri

Posta Sunucusu Ayarları :

E-Mail Server sekmesinden “Outgoing e-mail server (SMTP)” kutusuna mail sunucunuzun adini yazin. “Port number” kutusuna mail sunucusunun SMTP portunu yazin.

“Sender name” (Gönderen)
“E-mail address” (Gönderenin Mail Adresi)
Eger mail sunucunuz kimlik dogrulamasi yapiyorsa “My SMTP server requires authentication” secenegini secin ve kullanici adi ile sifreyi yazin.

Uygulayıp çıkınız.

Gönderim Ayarları :

WSUS Administration / Options / E-Mail Notifications / General

Send e-mail notification when new updates are synchronized” seçeneğini seçerek, güncellemeler hakkında, “Send status reports” seçeneğini seçerek durum bildirimlerini mail olarak alabilirsiniz.

Recipients bölümüne bilgilendirme mesajlarini alacak emailleri yazin. Birden fazla email adresi yazacaksaniz noktali virgul ile ayirin.

“Frequency box” (Gönderim sıklığı)

“Send reports at” (Gönderim saati)

“Recipients” (Alicilar)

Ayarlarını yapın ve uygulayın.

Bu yazıyı bilgisayarınıza PDF Formatında indirebilirsiniz :

DOWNLOAD

Kaynaklar :

http://www.microsoft.com/downloads/details.aspx?FamilyId=a206ae20-2695-436c-9578-3403a7d46e40&displaylang=en#Requirements

http://blogs.digitalortam.net/

http://www.hidayetaltun.com/wsus/

http://mshowto.org

http://www.syslogs.org/tag/wsus/

http://osman-shener-tr.blogspot.com

Patch management is by far the most important, and critical to perform IT security related task facing any organization. Today, any company that has selected Microsoft WSUS as their primary patch management solution…is putting themselves at risk, unnecessarily! The rate at which vulnerabilities are appearing these days is staggering, but not limited to Microsoft alone. Additionally, given the sheer number of updates and patches that vendors like Adobe, Real Player, and Firefox release each month, the patch management process can quickly overwhelm any organization…especially if they don’t have the right tools in place!

Gartner released a paper last year that spoke to this situation very clearly. The following is a excerpt from that paper; “Although Microsoft has improved WSUS, client feedback suggests that WSUS is not as rich in content and as robust in targeting and reporting as the focused patch solutions. Thus, organizations accepting WSUS as “good enough” have significantly higher labor costs for content analysis, testing and deployment. Although Microsoft is making improvements to WSUS, we do not believe it will be a best-of-breed solution for patch management”. (Publication Date: 3 March 2008 ID Number: G00155187, Author: Ronni J. Colville, Title: The Patch Management Market: Collision or Coexistence?)

It’s certainly not lost on me that the current economic climate is still forcing everyone to scrutinize operating expenses – and save money anywhere possible. Thus, the appeal to use technology like WSUS – which is “free”. Make no mistake…free is not free! On the surface, WSUS appears to be a solution that’s “good enough” – but as you peel back the onion, you will quickly discover the missing capabilities. The major drawback to using WSUS centers around its inability to address vulnerabilities associated with non-Microsoft applications, and even older Microsoft applications and operating systems. While the price of WSUS is certainly intriguing, its patch coverage and product support are very weak. Today, WSUS only covers a portion of the potential threats, and creates an enormous coverage / risk gap – that if left unmanaged subjects the user (knowingly or unknowingly) to what I would characterize as unnecessary risk!!

Key WSUS Drawbacks

• Non-Microsoft Application Coverage – The absence of this capability creates both risk, and the dedication of essential resources unnecessarily.
• Custom Application Coverage – How about “custom applications”. What if there are applications that have been deployed to support the needs of the organization…that no one in the world cares about but the company deploying it. How do those applications get patched…? Certainly not via using WSUS!!
• No Coverage For Non-Domain Joined Systems – WSUS assumes, and in fact, requires that all managed Windows systems be members of the domain to be discovered. Thus, you can’t protect what you can’t find.
• Online and Offline Virtual Machine Support – With the virtual sprawl continuing to expand, the ability to discover all forms of virtual systems is critical.
• Limited Reporting – WSUS 3.0 only offers the user access to a small number of reports – with some export capability. This is very limited at best.
• Architecture – WSUS relies solely on a series of agents to manage the patching function. Putting an agent on server is generally not a good idea because it can create an unnecessary, potential point of failure.
• Reboot Control - This is as especially critical for servers.  WSUS  does not allow pinpoint control over when systems are rebooted – during planned downtime. The absence of control here can present a great deal of difficulty – especially if critical servers reboot at a time when the shouldn’t.

What’s needed to truly address this growing and complex problem is a comprehensive, purpose built solution that can; 1) accurately assess either virtual or non-virtual machines for missing patches – either Microsoft or non-Microsoft, 2) once discovered…quickly remediate / deploy the required patches, and finally, 3) provides good, consumable reporting that clearly illustrates that the risk has been removed, and the environment has been restored to the desired state. Despite the fact that WSUS is a free utility, the disadvantages it presents should certainly make you think twice about relying on it to address one of your most critical IT security requirements.

Dave Eike
Shavlik Technologies

Damn WSUS.. Just filling up drives.. Patch management isnt always easy.. Especially if you forget to disable languages.

I recently was troubleshooting an issue with some failing software update installations being deployed via SCCM / WSUS, and finally found out what was affecting them. All of the failed updates were related to Microsoft Office, so that kind of tells you something right there. It turns out, the root cause of the installation failure was that the “Office Source Engine” (short name ‘ose’) was disabled.

A quick, easy way to re-enable the service remotely is to use Windows PowerShell. Here is a command you can issue to set the start mode to manual:

(Get-WmiObject -Query “select * from win32_service where name = ‘ose’” -ComputerName RemoteMachine).ChangeStartMode(“Manual”)

The error messages I was getting in the UpdatesHandler.log are below:

WSUS update (32cd1fb9-5401-4025-b8dc-22a3b41060cc) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (880f4592-a57e-4af6-ae6c-c2988519df4e) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (8fe60694-94c6-4568-8094-17e2e92045ea) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (938d8bbf-f928-4dac-baef-b66005583409) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (ae97d343-7c0d-4c06-9a62-67eff01890a9) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (bf20a84c-6662-4755-b60d-7fe3a090eb01) installation result = 0×80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (e33db88f-49ab-4cce-aa24-16d952526b6b) installation result = 0×80070643, Reboot State = NoReboot
Update execution failed.
WSUS update (f6e3e036-eaf1-4423-9eab-9359a23fcb9e) installation result = 0×80070643, Reboot State = NoReboot
Update execution failed.
WSUS update (f75401a0-0419-48fc-8011-bb0b30c061f8) installation result = 0×80070643, Reboot State = NoReboot
Update execution failed.

Update (2009-10-29): I thought I had posted this somewhere, but I guess not. While the suggested PowerShell code above would work for a one-off fix, a better way to manage this configuration would probably be to use the Microsoft Group Policy Preferences Client Side Extensions (CSE). You can use these GPO extensions to enforce service configurations for systems with the CSE installed, thus reducing helpdesk tickets resulting from improper configurations (whether done maliciously or non-maliciously).

Após alguns dias pensando a respeito de como facilitar minha própria vida, na hora de montar o relatório semanal do WSUS, resolvi arregaçar as mangas e tentar fazer de uma vez por todas um script para isso.

Objetivo

Listar a quantidade de computadores de 18 grupos diferentes.

Meu maior problema era entender a estrutura de tabelas do WSUS 3.0 SP1 para que eu conseguisse determinar quais tabelas eu deveria consultar pra chegar ao que eu queria.

Com a ajuda desta dicussão (fórum), tive uma luz, que após alguns instantes fizeram me chegar ao código abaixo, resolvendo totalmente meu problema:

USE SUSDB

DECLARE @TargetGroup nvarchar(30)
DECLARE @groupId uniqueidentifier

SELECT @TargetGroup = 'Nome do Grupo'

SELECT @groupId = ComputerTargetGroupId
FROM PUBLIC_VIEWS.vComputerTargetGroup
WHERE vComputerTargetGroup.Name = @TargetGroup

SELECT COUNT(FullDomainName) AS AR_ASA_Srv FROM tbComputerTarget
WHERE TargetID IN (SELECT TargetID FROM tbTargetInTargetGroup
WHERE TargetGroupID = @groupId)

Como usar o código acima?
Salve o script acima em um arquivo .sql e utilize a seguinte linha de comando para executá-lo (diretamente no servidor de WSUS):

sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query –i arquivo.sql

A couple of weeks ago the WSUS team released there SP2 for WSUS 3.0. Now the SCE team has announced that SCE 2007 SP1 support to upgrade to WSUS 3.0 Sp2.

Read the announcement on the SCE team blog

Hi,

da wir heute einen solchen Support Fall hatten hier nochmal der Hinweis: Um die neuen Group Policy Preferences (GPP) auf Windows XP/Windows Server 2003 und Vista anwenden zu können, MÜSSEN die Client Side Extensions (CSE) aus dem Artikel KB943729, auf den Windows XP/Server 2003 und Vista Systemen installiert sein!

Man kann die CSE´s (KB943729) manuelle installieren:
allerdings gibt keine lokalisierten Versionen, sondern nur nur englisch, was aber problos auf einem deutschen OS installiert werden kann. Hier die Downloads:

Windows Vista, 64-bit edition
Windows Vista, 32-bit edition
Windows Server 2003, 64-bit edition
Windows Server 2003, 32-bit edition
Windows XP, 64-bit edition
Windows XP, 32-bit edition

oder über die Automatische Installation des WSUS:
Dazu muss in den Download Optionen des WSUS unter “Optionen -> Produkte und Klassifizierungen -> Produkte: 2008 und Klassifizierung: Features” aktiviert sein , damit der Patch zur Installation angeboten wird. Nach einer WSUS Synchronisation mit Windows Update muss nach 943729 gesucht und zur Installation frei gegeben werden.

Zur Verwaltung der GPP´s benötigt man Windows Vista SP1/Windows 7 oder Server2008/R2, da man mit der GPMC aus den RSAT Tools die GPP´s konfiguriert! Die RSAT Tools müssen zunächst für Vista/Windows 7 runtergladen und installiert werden und dann überSystemsteuerung – Programme – Windows Funktionen Ein- und Ausschalten aktivieren.

Microsoft Remoteserver-Verwaltungstools für Windows Vista SP1 32-Bit Edition (KB941314)
Microsoft Remoteserver-Verwaltungstools für Windows Vista SP1 64-Bit Edition (KB941314)
Remote Server Administration Tools for Windows 7

Na dann, Viel Spass beim selber Testen!
CU

Download and install Microsoft SQL Server Management Studio Express on your WSUS 3 Server
Use Windows Authentication to connect to \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

Then run following query locally from WSUS server.

SELECT [Name]
,[IPAddress]
,[LastSyncResult]
,[LastSyncTime]
,[LastReportedStatusTime]
,[OSArchitecture]
,[Make]
,[Model]
,[BiosName]
,[BiosVersion]
,[BiosReleaseDate]
,[OSMajorVersion]
,[OSMinorVersion]
,[OSBuildNumber]
,[OSServicePackMajorNumber]
,[OSDefaultUILanguage]
FROM [SUSDB].[PUBLIC_VIEWS].[vComputerTarget]

if you are command line junkie use SQLCMD.exe

Prerequisite is : SQL Native client

…грузит систему на 100% — есть вероятность, что это делает служба windows update.

Проверить это (в консоли) можно так:

net stop wuauserv

если спустя минуты 3-5 после этой комманды загрузка спадает, тогда дело именно в обновлениях. Если же нет, то тогда в чем-то другом и тут я пока ничем помочь не могу.

Решений проблем с виндовс апдейтом может быть много. Разного рода вульгарные способы вроде отключения службы нахрен я не рекомендую, давайте тогда в случае чего ещё и руки с ногами врачи будут отрубать людям.

Куча решений приведена на http://ask-leo.com/comments_003020.php. Знают о проблеме также и микрософте

http://support.microsoft.com/kb/927891/
http://support.microsoft.com/kb/916089/

Избранные способы

1. дать виндовс апдейту свой svchost – путь он там и живет

sc config wuauserv type= own

2. Способ для корпоративных ребят – немножко сбросить WSUS

net stop wuauserv
net stop bits
net stop cryptsvc

wuauclt.exe /resetauthorization /detectnow

Файлик WSUSReset.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate]
"AccountDomainSid"=-
"SusClientId"=-
"PingID"=-

SELECT UT.DefaultTitle as [Title]

,UT.DefaultDescription as [Description]

,[MsrcSeverity]

,[KnowledgebaseArticle] as [KB]

,[SecurityBulletin]

,[PublicationState]

,[UpdateType]

,[InstallationRebootBehavior]

,[ArrivalDate]

,[Action]

,[Deadline]

,UA.[CreationDate] as [Approved On]

,[AdministratorName] as [Approved By]

FROM [SUSDB].[PUBLIC_VIEWS].[vUpdateApproval] as UA left join [SUSDB].[PUBLIC_VIEWS].[vUpdate] as UT on UA.UpdateID = ut.UPDATeID

Where AdministratorName <> ‘WUS Server’

order by [Approved On]

I read about BITS a few years back when they first started development on it. I remember thinking it looked interesting and the fact that you could use it in your own applications could prove to be useful one day. I’ve really not had a chance to look at it since then but just today I was trying to configure WSUS so I wouldn’t have to manually install the .NET framework on every last machine and wanted to know more about how WSUS works. Lo and behold WSUS uses BITS on the client computers.

So I did some searching and found this: Bitsadmin.exe: BITS Administration Utility. Neat, so all I need to do is run Bitsadmin at the command line and voila, I’ll have my WSUS download status, right? Wrong. It seems even though my machine is all patched and up to date, has 3 versions of Visual Studio on it including VS 2010, I did not have a copy of Bitsadmin.exe in my path. I even did a windows search for the file on c: and nada, nope, nothing. So, surprised that there was something in the windows universe that I had yet to install I searched for that and wound up here: Windows XP Service Pack 2 Support Tools. It seems there is no “Windows XP Service Pack 3 Support Tools” at the present.

So I download my latest discovery and install, then try running “Bitsadmin” at the console and, what, nothing? I close and re-open the console, and voila! I get: BITSADMIN version 2.0 …
Yeah! The install must of either updated my path variable or the console window somehow caches the list of files available to run, no matter re-starting worked. So, now I want to monitor the status of my windows download so I try bitsadmin /? and get… well I get way too much info to post here. I wind up running this command:
Bitsadmin /list
And get: nothing
Wha? Well, I’ll have to figure out what’s up with WSUS later, right now I want to get my new Bitsadmin toy doing something! It appears it’s able to download a file from a URI, the question is what am I going to find that I can download by URI? It needs to be a relatively good size for a good test of bits, a regular html page isn’t going to cut it. After some thinking about where I can find a unprotected exe I finally decide on FireFox, which seems ironic since it’s a Microsoft tool and the first thing I’m going to download with it is FireFox. I do a little searching and find this:
Index of /pub/mozilla.org/firefox/releases/3.5/win32/ca
and I decide to download this URI for my test:
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/ca/Firefox%20Setup%203.5.exe

So, back to bits. I do some more help doc reading and decide this is my command to run:
Bitsadmin /addfile FireFoxDownload “http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/ca/Firefox%20Setup%203.5.exe” c:\FireFoxSetup203.5.exe
No dice, I get an error about job name being invalid, so some more searching through the help file and /CREATE looks promising so I try:
Bitsadmin /CREATE /UPLOAD FireFoxDownload
Success! Then I re-run:
Bitsadmin /addfile FireFoxDownload “http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/ca/Firefox%20Setup%203.5.exe” c:\FireFoxSetup203.5.exe
and all seems well. Curious to the state of my download I try to query it:
Bitsadmin /list
hrm, seems the file is status SUSPENDED, that seems non optimal. More reading, huzzah! I try this:
Bitsadmin /resume FireFoxDownload
and then
Bitsadmin /list
and things appear to be working well. Every time I run Bitsadmin /list the bit amount increments. Finally it’s at 100% and I check my c:\ drive:
Again, odd, no c:\FireFoxSetup203.5.exe file anywhere. Back to the help doc. I run:
Bitsadmin /complete FireFoxDownload
and then go back to c: and the file is there. Now for my final test, will it run? Yep, works like a charm, er, one unfortunate side affect though. It seems I’ve downloaded the french version of FireFox.

During this process I discovered another option. There appears to be a /TRANSFER option that will download the file in one easy step. So back to the FF website to try and find the English version. I’ve decided to try: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/en-US/Firefox%20Setup%203.5.exe
Here’s my new command:
Bitsadmin /transfer FireFoxDownload /download “http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/en-US/Firefox%20Setup%203.5.exe”
and I get:
Invalid argument
hrm, I was hoping to avoid inputting priority and ACL, there does not seem to be a indication as to what valid values for /PRIORITY are. I’m going to guess it’s a integer, here goes:
Bitsadmin /transfer FireFoxDownload /download /priority 1 “http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/en-US/Firefox%20Setup%203.5.exe”
Aaannndddd…. no good. I google search and come up with this:
The priority is either FOREGROUND, HIGH, NORMAL, LOW, or UNKNOWN.
Once again:
Bitsadmin /transfer FireFoxDownload /download /priority high “http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/en-US/Firefox%20Setup%203.5.exe”
Invalid argument?!? I’ll be back when I have the command that actually works….
This guy just posted the Bitsadmin /?.
Hrm, better MS doc: Bitsadmin /transfer.

Finally!! Working:
Bitsadmin /transfer FireFoxDownload /download /priority high “http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/en-US/Firefox%20Setup%203.5.exe” “c:\FirefoxSetup203.5en.exe”
Oops, I forgot the local path. Anyway, time for the file is still intact test, run it from “c:\FirefoxSetup203.5en.exe”
YES! Worked like a charm.

To recap:
How to download a file Using BITS and queuing:
Bitsadmin /CREATE /UPLOAD FireFoxDownload
Bitsadmin /addfile FireFoxDownload “http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/ca/Firefox%20Setup%203.5.exe” c:\FireFoxSetup203.5.exe
Bitsadmin /resume FireFoxDownload
Bitsadmin /list –Once file is 100% run the next line:
Bitsadmin /complete FireFoxDownload

How to download a file using BITS immediately:
Bitsadmin /transfer FireFoxDownload /download /priority high “http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.5/win32/en-US/Firefox%20Setup%203.5.exe” “c:\FirefoxSetup203.5en.exe”

Happy BITSing!
– Anthony

Prendete queste variabili: un dominio, Wsus 3.0, Office e Thunderbird come client di posta elettronica predefinito. Fatto? Agitatele in una scatola. Fatto? Ora di norma non succede niente, ma se siete sfortunati, per una qualche congiunzione astrale… può capitare che ad ogni aggiornamento fatto da Wsus, in alcuni client nel dominio, Thunderbird rimane il client di posta predefinito ma in Internet Explorer (Strumenti->Opzioni Internet->Programmi ->Posta elettronica) si imposta Outlook.

Questo comporta che, l’opzione (per me inutile ma per altri fonte di perdita del sonno) del tasto destro Invia a-> Destinatario posta, per allegare un file in un’email, non apra una nuova email con il file in allegato in Thunderbird, ma Windows cerca di aprire Outlook.

Soluzioni trovate, tre:

1. il collega si rassegna
2. il collega ogni volta imposta in Internet Explorer,  Thunderbird come programma per la posta elettronica
3. si ignora questo problema e invece di usare questa benedetta opzione Invia a-> Destinatario posta, si crea una voce nel menu contestuale del tasto destro che fa la stessa funzione.

La soluzione 3 è la seguente. Si crea un file di testo, si inserisce il testo:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\Shell\Allega in Thunderbird\Command]@=”C:\\Thunderbird\\thunderbird.exe -compose attachment=file:///%1″

si da un nome al file e si cambia l’estensione in .reg.

Il testo Allega in Thunderbird è il testo che comparirà nel menu cliccando sul file con il tasto destro.

C:\\Thunderbird\\thunderbird.exe è il percorso del mio thunderbird.exe, personalizzate il vostro. Le \\ non sono una svista, dovete scrivere così.

Eseguite il file con estensione .reg così creato e vi ritrovere la nuova voce “Allega in Thunderbird” nel menu del tasto destro quando cliccate sopra ad un file.

PS il file va a modificare il file di registro di Windows, quindi fate attenzione e se fare casino non è colpa mia.

Fonte: qualche ora passata su Google

Ya liberaron el nuevo service pack para WSUS (http://support.microsoft.com/kb/972455), con mejoras de las cuales rescato:

• Normalmente en los reportes de estado se tomaban en cuenta las actualizaciones que no habían sido aprobadas, ahora reporta respecto a las  que son aprobadas.
• Dentro de las reglas de auto aprobación, se puede seleccionar la fecha límite para la instalación (deadline).
• Soporte para Windows 2008 R2 y Windows 7, además de IP V6.
• Por supuesto que mejoras en la rapidez de los chequeos de estado y desempeño en general.

Provecho!!