Vaya por delante que opino que usar Windows en un centro educativo es, salvo casos muy justificados, un disparate económico, ético y tecnológico. Pero por desgracia esa puerta quedó abierta en tiempos pasados y debemos lidiar con la situación como buenamente podamos.
1. Parte de guerra.
Una vez tienes instalados tus Windows "pelados" aparte de los problemas típicos de gestión de usuarios y administración te encuentras con la cuestión de sus actualizaciones, que tiene una idiosincrasia especial en un entorno como el nuestro. Repasemos:
Primero. Cualquier usuario, incluidos los defensores mas acérrimos, habrán comprobado que Windows
tiene la irritante costumbre de actualizarse sin control y sin contemplaciones de forma extemporánea: al iniciar, al apagar o en medio de la operación de un PC. De una extraña manera, estas actualizaciones incluso no dudan en arrasar cuando les parece con el arranque dual haciendo desaparecer Linux del menú de arranque. Esto en mi opinión roza lo delictivo.
Segundo. Windows tiene un sistema de actualizaciones totalmente ilógico: si dejas un equipo sin actualizar 6 meses al lanzar el update no instala lo último, sino que
pasa por casi toda la secuencia de actualizaciones que se han quedado atrás (pocas veces una actualización es descartada en favor de otra posterior), reiniciando el equipo varias veces. Eso, para la gente razonable acostumbrada a derivados de Debian y a las rolling relaease como mi querida Manjaro es sencillamente inconcebible. Me ha llegado a pasar que instalas un Windows 7 en una hora y luego te pasas 20 horas descargando actualizaciones por fases de descarga-instalación-reinicio hasta tenerlo al día.
Por otro lado, el proceso de actualización es tremendamente oscuro y nunca sabes que está pasando y si el sistema se ha quedado parado en alguna operación. Sabes cuando empieza y cuando acaba, pero no como avanza. Para los acostumbrados a la verbosidad de las actualizaciones en Linux este mutismo es incomprensible.
Tercero. Como ya avisamos en su momento a la gente que decide, para poner orden en este caos
hace falta un sistema que nos permita administrar y dosificar el flujo de actualizaciones. Eso implica un Windows Server y un servicio
WSUS por centro junto con el hardware para ello, lo cual representa un sensible gasto adicional en dinero y tiempo para administrarlo. Esto no se tuvo en cuenta por las mentes pensantes que decidieron adquirir licencias de Windows sin tino y nos dejaron el papelón a los de abajo.
También puedo hablar según mi experiencia: habiendo servido durante varios años en
ICM, la antigua Agencia de Informática y Comunicaciones de la Comunidad de Madrid (muy conocida por colaborar con las tramas corruptas Púnica y Lezo; tranquilos: yo soy inocente, todo eso pasó mayormente mientras estaba de excedencia) donde todo se basaba en Windows. Incluso con toda la infraestructura de clientes y servidores Windows montada para gestionar las actualizaciones de forma controlada los problemas en los clientes eran constantes: parches que se enrocaban en una instalación iniciada e interrumpida infinitamente, equipos en que fallaba algo y se quedaban atrás sin actualizar, errores y pantallazos azules en arranques tras actualizaciones fallidas... y todo esto con Windows XP, en los que el que ritmo de actualizaciones era mucho mas reducido que en los Windows posteriores.
Cuarto. Para mas INRI,
esto último no sirve nada tan pronto como comprendes la realidad de funcionamiento de los PC de los centros educativos. Esto no es una oficina al uso donde los PC se encienden de 8 a 15 o de 9 a 17. Un PC en un centro educativo se enciende y se apaga de forma aleatoria a lo largo del día según el uso en las materias y horarios de clase. Incluso podemos encontrarnos con PC que no se encienden durante muchos días y de repente luego se encienden una mañana entera con 3 reinicios al cambiar de clase. Evidentemente
disparar unas actualizaciones que pueden tardar horas en un entorno tan aleatorio es un proceso abocado a la catástrofe: tanto por el consumo de ancho de banda que se incrementa de golpe al encender un grupo de PC de alumnos, así como por el ralentizamiento del PC asociado a la actualización y los problemas derivados de apagarlos cuando están a medias.
Cinco. Podríamos pensar que los PC de uso de los profesores (salas comunes, aulas, departamentos) si que están encendidos de forma continua. Falso: son ordenadores de uso compartido y una de las pequeñas luchas que tenemos los administradores informáticos es limitar la pulsión que tienen muchos usuarios de apagar el sistema operativo cuando se acaba su sesión, máxime teniendo en cuenta que en 5 minutos va a haber otro docente sentado en ese mismo sitio. Pues bien:
no hay manera, cuando alguien quiere apagar, apaga.
Seis. ¿Puede empeorar la cosa? Si:
las aulas de portátiles. Nada mas terrible que ir a guardar un portátil en un armario de carga porque acaba la clase y encontrarnos que nos dice que esperemos porque hay que instalar 13 actualizaciones. O encenderlo para empezar la clase y esperar 10 minutos a que se actualice. Pero eso no es todo: tenemos 20 portátiles
conectados a un punto de acceso wifi normal y corriente pugnando por actualizar, descargando megas y megas cada uno e impidiendo el uso normal de todos los dispositivos conectados a la misma wifi. Como seguramente en una hora de clase no de tiempo a descargar todo en la próxima sesión volveremos a la casilla de salida.
2. Estrategias paliativas.
Ante este panorama no nos queda otra que lidiar como buenamente podamos con todo ello. Si quedamos las actualizaciones a su libre albedrío la tragedia en forma de sistemas dañados por el apagado en medio de una actualización o redes colapsadas está garantizada. Parafraseando el proverbio chino: simplemente tenemos que sentarnos a la orilla del río y esperar hasta que pasen los Windows muertos flotando corriente abajo. El problema es que al final esos Windows tenemos que resucitarlos nosotros.
En mi caso he optado por dos estrategias para evitar la debacle:
- Cuando es posible por la potencia del equipo cliente virtualizo los Windows y los dejo con las actualizaciones desactivadas. Tengo un master que actualizo de vez en cuando en un PC concreto y distribuyo luego el fichero .VDI (imagen del disco duro) a todos los demás.
- Si no es posible virtualizar, porque los PC andan justitos de procesador y memoria opto por dejar un arranque dual y: desactivar en la medida de lo posible las actualizaciones automáticas de Windows, usar un sistema basado en wsusoffline, como recomienda nuestro compañero Esteban, para actualizar contra un repositorio interno al IES y no contra Internet (con lo cual ahorramos tráfico de red) y cada cierto tiempo me toca perder varios días actualizando semi-manualmente los equipos.
Vamos a ver esto con detalle.
3. Parar, reanudar y limitar las actualizaciones.
No es plato de buen gusto parar las actualizaciones de un PC, se supone que incluyen mejoras y parches contra agujeros de seguridad como Wannacry, Meltdown o Spectre. Pero cuando la alternativa es tener el aula parada y los usuarios malhumorados porque todo el tiempo y ancho de banda se va en actualizar dices "¡pero que coño!" y paras todo.
La forma más efectiva que he encontrado de parar las actualizaciones automáticas es con estos comandos que se pueden meter en un script:
sc config wuauserv start= disabled
net stop wuauserv
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU /v NoAutoUpdate /t REG_DWORD /d 1 /f
Con esto el Windows queda congelado en el tiempo salvo que Microsoft use algún truco artero para colarnos algo, tal como hace con esas instalaciones de Cortana u OneDrive que reaparecen después de haberlos eliminado una y otra vez. Si queremos volver a activar haremos los pasos contrarios:
sc config wuauserv start= auto
net start wuauserv
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU /v NoAutoUpdate /t REG_DWORD /d 0 /f
Otra opción que puede resultar interesante es usar una característica que tiene Windows de definir una conexión inalámbrica de red como "metered" o de uso medido. Eso viene a significar que le avisamos de que esa conexión nos cuesta dinero cada megabyte y que por tanto,
tenga ojito con lo que se descarga por ella. Pensemos por ejemplo en una conexión móvil 4G, un operador de wifi o el futuro Starlink de Elon Musk, que nos facturase por datos transferidos.
Para ello debemos establecer la conexión a la red y una vez hecha tecleamos:
netsh wlan show profiles
Esto nos mostrará el nombre de la conexiones wlan (redes wifi o 4G), por ejemplo algo así como "Airtel-WRTR301GN-8897_1". Una vez sabido el nombre, con:
netsh wlan show profile name="Airtel-WRTR301GN-8897_1"
Vemos los parámetros de la conexió. En ellos el parámetro "Cost" puede valer Unrestricted (no limitado) o Fixed (limitado). Por tanto, si queremos indicar que la conexión es metered hacemos:
netsh wlan set profileparameter name=”Airtel-WRTR301GN-8897_1″ cost=Fixed
Esto hará que Windows se lo piense antes de consumir ancho de banda en una actualización por esa conexión. Pero, ojo, esto no descarta todas las actualizaciones y las que se consideren críticas se realizarán. Aunque está concebido para conexiones inalámbricas, también podemos activarlo en conexiones cableadas
trasteando el registro.
4. Encauzar las actualizaciones con WSUS Offline Update.
WSUS Offline Update es un sistema montado para realizar las actualizaciones de los Windows/Office usando la red local y minimizando el tráfico externo. Incluso permite actualizar Windows/Office sin conexión a Internet, descargando las actualizaciones a un pendrive y actualizando luego con él. Yo lo descubrí, como tantas otras cosas, gracias a mi compañero
Esteban.
Todo rota en torno a 3 elementos:
- Una aplicación/script que descarga las actualizaciones y parches disponibles para los sistemas seleccionados.
- Un repositorio donde guardar lo descargado. Traduciendo: una carpeta local o de red donde guardar los archivos.
- Una aplicación/script que examina el sistema Windows y actualiza con los parches pendientes.
Una visión detallada del sistema la
podemos encontrar aquí.
En mi caso no he usado las aplicaciones gráficas para realizar las tareas, ya que como se deducirá me va mas la línea de comandos. Además he intentado que las dos primeras partes se realicen con Linux y un servidor samba. Solo la parte de aplicación de las actualizaciones es, evidentemente, sobre Windows. Para ello me he guiado por
este manual.
En un servidor auxiliar creo una carpeta /datos/wsus, con permisos 777 para todo su contenido. Sobre esa carpeta descomprimo la
última versión de wsusoffline, que a fecha de escribir este post es la
11.1.1.
Una vez descomprimido el .zip escribo el script que me hará la descarga de los parches y actualizaciones para los sistemas que le indique:
# cat /datos/wsus/update.sh
bash /datos/wsus/wsusoffline/sh/download-updates.bash w100 esn /includedotnet /includemsse /includewddefs /verify
bash /datos/wsus/wsusoffline/sh/download-updates.bash w63-x64 esn /includedotnet /includemsse /includewddefs /verify
bash /datos/wsus/wsusoffline/sh/download-updates.bash w100-x64 esn /includedotnet /includemsse /includewddefs /verify
# chmod +x datos/wsus/update.sh
Este script descarga lo que haya de Windows 10 (64 y 32 bits) y Windows 8 (64 bits). Mirar la documentación para ver todas las posibles opciones de descarga (Windows 7, Office, Visual C++, .NET, ...). Lanzamos la ejecución del script y nos vamos a hacer otras cosas, porque tarda un rato en descargar todo:
# /datos/wsus/update.sh
Cuando termina, vemos que ha hecho:
# du -sh /datos/wsus/wsusoffline/client
2,6G w100
4,8G w100-x64
1,9G w63-x64
# ls -1 /datos/wsus/wsusoffline/client/w100-x64/glb/
windows10.0-kb3172729-x64_bb12a14ec3891ec0a9e24edb529632263783d389.cab
windows10.0-kb3172729-x64_f4fc9775baa98c176f43e87c40088231a884122b.cab
windows10.0-kb3173427-x64_d95e56e499e2c281a1f59585221dc891253414c7.cab
windows10.0-kb3173427-x64_e3da65fe753d24a1759cdd029028cde743a62a23.msu
windows10.0-kb3173428-x64_52fa3686737353fae20ab55fa9c924bd90558a31.cab
windows10.0-kb4035632-x64_ea26f11d518e5e363fe9681b290a56a6afe15a81.msu
windows10.0-kb4049011-x64_a58e4c340939a7b23b86055a18abdc9c59308094.msu
windows10.0-kb4049065-x64_f92abbe03d011154d52cf13be7fb60e2c6feb35b.msu
windows10.0-kb4056887-x64_0fcf1ff448cea9474ea089a3d866beeb7212cec1.cab
windows10.0-kb4056887-x64_12a57a1104466ca878eb096fefa6c6babe520810.cab
windows10.0-kb4056887-x64_1e5c03724988979684c35a5493829e4abe9bdbfc.cab
windows10.0-kb4056887-x64_57d92c622280f34d0ee271a9c58fdce91c3c6808.cab
windows10.0-kb4056887-x64_8ad98c5fb14f2938536d794074a5b901b6eb0d72.cab
windows10.0-kb4056888-x64_5943823d032a25e40f8eee1613aa849d3963bd1d.cab
windows10.0-kb4056890-x64_2d0216b0e6b49f457e5111fbd7d766984af3f6cf.cab
windows10.0-kb4056891-x64_99b9dadbd6a71c8c9ca58b8e53285f8320dd32e3.cab
windows10.0-kb4056892-x64_39198b373a07390a3afdf2a64d19f24d59fca7a6.cab
windows10.0-kb4056893-x64_f025805bafd32c5f9d7ca37eb255a894dfb025d8.cab
windows10.0-kb4058702-x64_4ed8d0df4f3c190d3e423bf287d7e95a21a9124a.msu
Y ahí vemos todos los ficheros con las distintas actualizaciones y parches descargados esperando para ser aplicados según necesite el cliente Windows. Este script lo ejecutaremos de vez en cuando o al menos cuando se actualice wsusoffline.
Estos ficheros hay que compartirlos usando una carpeta samba de solo lectura accesible desde los Windows:
# cat /etc/samba/smb.conf
...
...
[wsus]
comment = WSUS Windows Updates
path = /datos/wsus
writable = no
browseable = yes
guest ok = yes
force directory mode = 0777
...
...
Reiniciamos samba y desde un Windows podemos abrir una ventana de comandos con credendiales de usuario administrador y teclear:
net use z: \\ip-servidor\wsus /persistent:no
Z:\wsusoffline\client\cmd\DoUpdate.cmd
Con lo cual empezará el laaaargo proceso de actualizaciones, que puede durar varias horas. En la ventana de terminal nos va informando escuetamente de cada parche aplicado. No nos desanimemos: si fuese mediante actualizaciones online podría tardar varios días y saturar la conexión de red del centro. De esta manera al menos tenemos controlado lo que se va haciendo y que se va actualizando.
5. Cosas a tener en cuenta.
Esto no es un camino de rosas, simplemente es algo para aminorar los problemas. Por eso debemos tener en cuenta varias cosas:
Después de todas estas actualizaciones es bueno saber en que versión tenemos el Windows. Por ahí se comenta que ejecutando en una consola Powershell:
Get-CimInstance Win32_OperatingSystem | Select-Object buildnumber,version
Se muestra la versión, pero es falso ya que no sale completo todo el número de compilación. La manera de saberlo es con:
winver
Nos muestra:
Este Windows tiene por tanto en el momento en que escribimos esto la versión 1709, compilación 16299.192. Esta bastante actualizado a día de hoy, si buscamos en internet el "Historial de actualizaciones de Windows 10" vemos:
Podemos ver que nuestro Windows está en la compilación .192 y según la página de Microsoft posteriormente "sólo" han salido la 201, 214 y la 248. Cuando empecé a elaborar esta entrada ibamos por la 214 y ya ha salido otra, ahí es nada. Es verlo y me da la bajona... vaya cruz.
